When draining the socket in IServerConnection, we would previously
handle each incoming (local endpoint) message as it came in.
This would cause unexpected things to happen while blocked waiting
for a synchronous response. That's definitely not what we want,
so this patch puts all of the incoming messages in a queue and does
a separate pass over the queue to handle everything in order.
This matches what we're already calling the server-side subclasses
better, though we'll probably want to find some better names for the
client-side classes eventually.
This patch introduces code generation for the WindowServer IPC with
its clients. The client/server endpoints are defined by the two .ipc
files in Servers/WindowServer/: WindowServer.ipc and WindowClient.ipc
It now becomes significantly easier to add features and capabilities
to WindowServer since you don't have to know nearly as much about all
the intricate paths that IPC messages take between LibGUI and WSWindow.
The new system also uses significantly less IPC bandwidth since we're
now doing packed serialization instead of passing fixed-sized structs
of ~600 bytes for each message.
Some repaint coalescing optimizations are lost in this conversion and
we'll need to look at how to implement those in the new world.
The old CoreIPC::Client::Connection and CoreIPC::Server::Connection
classes are removed by this patch and replaced by use of ConnectionNG,
which will be renamed eventually.
Goodbye, old WindowServer IPC. You served us well :^)
This patch adds these I/O counters to each thread:
- (Inode) file read bytes
- (Inode) file write bytes
- Unix socket read bytes
- Unix socket write bytes
- IPv4 socket read bytes
- IPv4 socket write bytes
These are then exposed in /proc/all and seen in SystemMonitor.
Instead of using the generic block mechanism, wait-queued threads now
go into the special Queued state.
This fixes an issue where signal dispatch would unblock a wait-queued
thread (because signal dispatch unblocks blocked threads) and cause
confusion since the thread only expected to be awoken by the queue.
Instead of waking up repeatedly to check if a disk operation has
finished, use a WaitQueue and wake it up in the IRQ handler.
This simplifies the device driver a bit, and makes it more responsive
as well :^)
There was a race window between instantiating a WaitQueueBlocker and
setting the thread state to Blocked. If a thread was preempted between
those steps, someone else might try to wake the wait queue and find an
unblocked thread in a wait queue, which is not sane.
The kernel's Lock class now uses a proper wait queue internally instead
of just having everyone wake up regularly to try to acquire the lock.
We also keep the donation mechanism, so that whenever someone tries to
take the lock and fails, that thread donates the remainder of its
timeslice to the current lock holder.
After unlocking a Lock, the unlocking thread calls WaitQueue::wake_one,
which unblocks the next thread in queue.
We never want to alpha blend when rendering the terminal buffer, so we
can just use clear_rect() and avoid trouble.
This fixes an issue with inconsistent translucency in the terminal app
when setting a custom background opacity.
This patch adds InsertTextCommand and RemoveTextCommand.
These two commands are used to ... insert and remove text :^)
The bulk of the logic is moved into GTextDocument, and we now use the
command's redo() virtual to perform the action. Or in other words, when
you type into the text editor, we create an InsertTextCommand, push it
onto the undo stack, and call redo() on it immediately. That's how the
text gets inserted.
This makes it quite easy to implement more commands, as there is no
distinction between a redo() and the initial application.
This patch converts the undo stack from GTextDocument into GUndoStack,
and GTextDocumentUndoCommand now inherits from GCommand.
Let's turn this into a generic mechanism that can be used to implement
undo/redo in any application. :^)
The CNetworkJob::on_finish hook will be invoked both for success and
failure, but there will only be a m_job->response() in the success case
so we have to null-check it before using it.
This should have been obvious from the "->"
Callers of draw_pixel() are not expecting it to apply translation since
they will have already done that themselves.
This was causing draw_line() with thickness>1 to have an offset applied
in case the painter was already translated.
