Previous implementation based on the actual load of each core and share
each thread has in that load turned up to be very problematic when
balancing load on very heavily loaded systems (i.e. more threads
consuming all available CPU time than there is logical CPUs).
The new approach is to estimate how much load would a thread produce
if it had all CPU time only for itself. Summing such load estimations
of each thread assigned to a given core we get a rank that contains
much more information than just simple actual core load.
* Previously PE binaries would trigger the "incorrectly
executable" dialog. Now we get a special message for
B_LEGACY_EXECUTABLE and B_UNKNOWN_EXECUTABLE
* Legacy at the moment is a R3 x86 PE binary. This could
be extended to gcc2 binaries someday far, far, down the
road though
* The check for legacy is based on a PE flag I see
set on every R3 binary (that isn't set on dos ones)
* Unknown is something we know *is* an executable, but
can't do anything with (such as an MSDOS or Windows
application)
* No performance drops as we do the PE scan last
* Tested on x86 and x86_gcc2
Deleting the BIO while it's still waiting on a read() in another thread
will lead to a crash when the socket is eventually closed. Close the
socket first, so the read() is unlocked, then safely delete the BIO.
* Also update dependencies cmake and libxml2
* Bonus package: Milkytracker
This is for gcc2hybrids only. gcc4 and x86_64 users are welcome to
contribute an haikuwebkit package for their architectures using the
haikuporter recipe.
This field forces kernel to track each CPU load all the time. It is not
a problem with the current scheduler on a multicore systems, but on
single core machnies or with any other future scheduler this field may
become just an unnecessary burden. It isn't difficult for an application
to compute CPU load by itself when it needs it.
* use the templated BLayoutBuilder
* reduced top inset to be the same as to all sides
* SetExplicitMinSize of the LayoutView so it can't shrink to
illegibility
* set slightly smaller window default size (on small screens)
When calling Stop(), we expect the request thread to exit as soon as
possible. Closing the connection unlocks it from any blocking read() or
write(), avoiding some lockup situations.
* My BeagleBone gcc defines __ARMEL__ but not
__ARM__ which breaks the native tool builds
* As ARM was originally Little Endian, we assume
__ARM__ means as such.
* Look for Big Endian ARM and define the needed big
endian preprocessors
fMessageAfterSave capture what was to be done after a file panel was
used. For example, picking up quitting the app after the user saved
unsaved changes. The bug was that when trying to quit IOM, deciding to
save, but then cancelling the file panel, the quitting stopped (as expected).
But then the next time the document was saved, IOM quit unexpectedly.