If WaitQueue::wake_all, WaitQueue::wake_one, or WaitQueue::wake_n
is called but nobody is currently waiting, we should remember that
fact and prevent someone from waiting after such a request. This
solves a race condition where the Finalizer thread is notified
to finalize a thread, but it is not (yet) waiting on this queue.
Fixes#2693
These changes solve a number of problems with the software
context swithcing:
* The scheduler lock really should be held throughout context switches
* Transitioning from the initial (idle) thread to another needs to
hold the scheduler lock
* Transitioning from a dying thread to another also needs to hold
the scheduler lock
* Dying threads cannot necessarily be finalized if they haven't
switched out of it yet, so flag them as active while a processor
is running it (the Running state may be switched to Dying while
it still is actually running)
We need to be able to prevent a WaitQueue from being
modified by another CPU. So, add a SpinLock to it.
Because this pushes some other class over the 64 byte
limit, we also need to add another 128-byte bucket to
the slab allocator.
The Lock class still permits no reason, but for everything else
require a reason to be passed to Thread::wait_on. This makes it
easier to diagnose why a Thread is in Queued state.
Change: on_link_hover(String) -> on_link_hover(URL)
Also, we now fire the hook when a link is unhovered as well, allowing
the embedder to react to nothing being hovered anymore.
This removes the remaining flicker in the WebContentView widget and
makes it feel pretty good to use it. :^)
The increase in memory use is something we'll have to address in the
future with more sophisticated solutions like tiling, etc.
Instead of painting synchronously whenever a Paint request comes in,
the WebContent process will now buffer pending paints and coalesce
them and defer the actual paint using a zero-timer.
This significantly reduces flickering already, without doing any
double-buffering in the WebContentView widget.
Activating a "#foo" fragment link will now be handled internally by
the Frame instead of involving the widget layer.
If the viewport needs to be scrolled as a result, we will simply ask
the PageClient to scroll a new rect into view.
Take one small step towards #2357.
Handle completing barewords starting with '-' by piping the requests to
the Shell::complete_option(program_name, option) :^)
Also implements completion for a single builtin (setopt) until we figure out how
to handle #2357.
This builtin sets (and unsets) boolean flags that alter the behaviour of
the shell.
The only flags added are
- inline_exec_keep_empty_segments: Keep empty segments in the result of
splitting $(...) by $IFS
- verbose: Announce each command before executing it
It should be noted that the (rather extreme) verbosity of the names is
intentional, and will hopefully be alleviated by the next commit :^)
This commit also removes the ExecutionInputType and directly uses
RefPtr<Shell> instead, since nothing else is needed for execution
purposes, and also makes the shell refuse to evaluate commands with
any sort of syntax error.
This commit also completely reworks the execution, highlighting and
completion model to work with the new AST.
New additions:
- $(...) stdout captures
- fd>&fd redirections
- fd>&- redirections (close fd)
- read-write redirections (<> path)
- completely event-based execution
- the weird idea of allowing the user to redirect the shell's own fds
- variables in strings
- local variables
- minimal list support
- adding hyperlinks to all paths that exist
After adding the scrolling feature, content available space reduced and
thus the bitmap size was always larger, than the inner size.
This lead to the horizontal scrollbar always beeing engaged.
FileBackedFileSystem is one that's backed by (mounted from) a file, in other
words one that has a "source" of the mount; that doesn't mean it deals in
blocks. The hierarchy now becomes:
* FS
* ProcFS
* DevPtsFS
* TmpFS
* FileBackedFS
* (future) Plan9FS
* BlockBasedFS
* Ext2FS
The WebContentView widget now inherits from GUI::ScrollableWidget and
will pass its scroll offset over to the WebContent process as it's
changing. This is not super efficient and can get a bit laggy, but it
will do fine as an initial scrolling implementation.
Just like the single-process Web::PageView widget, WebContentView also
paints scrolled content by translating the Gfx::Painter.
