When we encounter a wired page that we'd have to unmap to map our newly
allocated one, we need to get rid of the latter before unlocking
everything and waiting for the wired page. Otherwise we'd leave things
in an inconsistent state (a page from an upper cache shadowing a mapped
page from a lower cache).
... in case we'd need to unmap a page that is wired.
Fixes the immediate issue of #10977. There's a problem remaining (as
discussed in comment 1): If two threads want to wire the same page at
the same time (which led to the assertion being triggered), they will
now deadlock, waiting for each other to remove the pre-registered
VMAreaWiredRange.
The thread that is being [un]scheduled already has its time_lock locked
in {stop|continue}_cpu_timers(). When updating the TeamTimeUserTimer,
the team is asked for its cpu time. Team::CPUTime() then iterates the
threads of the team and locks the time_lock of the thread again.
This workaround passes a possibly locked thread through the relevant
functions so Team::CPUTime() can decide whether or not a thread it
iterates needs to be locked or not.
This works around #11032 and its duplicates #11314 and #11344.
when uninitializing a partition or a disk (removing the partition
table), check that all partitions from that table are unmounted, as they
are about to become invalid.
Fixes#8827.
Python 2.7.x has *much* better cross-compiling support so that it's now
actually possible to properly cross-compile Python during the bootstrap.
Before, it would just depend a lot on luck and the build host used, now
it even cross-compiles on OS X.
This means it's now possible to build a working bootstrap image on OS X!
:)
- Allows one to choose the type which the current expression
should be evaluated as.
- Don't attempt to evaluate expression if the input field is
currently empty.
- Remove dependency on MAPM/ExpressionParser. Consequently also adjust
CliDumpMemoryCommand, InspectorWindow and WatchPromptWindow to use
CLanguageExpressionEvaluator for address input evaluation.
CLanguageExpressionEvaluator:
- Revise to make use of Number class rather than MAPM. In the process,
implement support for bitwise operators.
SourceLanguage/CLanguageFamily/CLanguageExpressionEvaluator:
- Adjust interface for expression evaluation to allow specifying the
type to evaluate the expression as. Adjust implementing classes
accordingly.
ExpressionEvaluationWindow:
- Adjust to new expression interface. For now defaults to 64-bit integer
type, UI for type selection to be added.
- This class abstracts out the underlying type of a value, and handles
all the basic mathematical logical operators accordingly. Replaces
the MAPM type previously used for these respective operations.
The language and formatting conventions can now only be set when
creating the objects. This removed the needs for locking them when
formatting to avoid some other thread changing the format while it's
being used.
Adjust tests and DeskBar TimeView to the API changes.
- CLanguageExpressionEvaluator now handles all the basic logical
comparison operators. Bitwise operators still to come, as some
of those may possibly require modifications to the MAPM library.
- Separate operator parsing out into its own function, and refactor
it to handle multi-character operators. These aren't yet handled
by the parser itself though.
- Using BMessenger as an indirect lock is unnecessary, as
BLooper::Lock() checks if the current looper is valid via the global
looper list directly.
- Fix race conditions. When asked to show various subwindows, lock them
before calling Activate(), as the window could otherwise potentially
quit in between us checking pointer validity and calling Activate().
- _GetActiveSourceLanguage() needs to acquire a reference to the language
object in the case where it's retrieved from the active source code.
Otherwise, an unbalanced release would take place when creating the
expression window, leading to crashes.
Thanks to Stephan for reviewing.
Although done with the best intentions, the usage of #warning in the
ARM build makes it hard to see what's going on, or see any "real"
warnings.
Remove at least this particularly often triggered one, so we can
have a relatively "quiet" build again...
Not yet visible. But the package list area in the main window has a card
layout now and a second (hidden) page for featured packages. Which packages
are visible there will depend on the prominence value from the web-app
and other parameters later (suggestions based on packages already installed
and user-ratings). At the moment, there is no mechanism for updating the
package list when package info is retrieved asynchronously, even from the
cache. Also, the view should switch to the list when searching and perhaps
in other situations as well, like selecting a category or when no packages
would be featured. And clicking featured packages does not yet select them in
the info area...
Currently a vertically scrollable container for views which are similar
to the title area in the package info view (and share most code, but it
will diverge later on). Untested and not yet used.
Package contents are scanned to find deskbar links. If a package has less
than four links, they will be offered in separate "Open <link name>" buttons
in the package info area. Usually, this results in one button to open the
main application from the package. If the heuristic proves to be not good
enough, this could be improved of course.
Rene Gollent