Process teardown is divided into two main stages: finalize and reap.
Finalization happens in the "Finalizer" kernel and runs with interrupts
enabled, allowing destructors to take locks, etc.
Reaping happens either in sys$waitid() or in the scheduler for orphans.
The more work we can do in finalization, the better, since it's fully
pre-emptible and reduces the amount of time the system runs without
interrupts enabled.
Replace Process::m_being_inspected with an inspector reference count.
This prevents an assertion from firing when inspecting the same process
in /proc from multiple processes at the same time.
It was trivially reproducible by opening multiple FileManagers.
Don't stack notifications on top of each other, instead put them below
one another on the y axis.
This will obviously break if the screen fills with notifications, but
that's a FIXME for now. :^)
This patch adds NotificationServer, which runs as the "notify" user
and provides an IPC API for desktop notifications.
LibGUI gains the GUI::Notification class for showing notifications.
NotificationServer is spawned on demand and will unspawn after
dimissing all visible notifications. :^)
Finally, this also comes with a small /bin/notify utility.
This allows RefPtr to be stored in a HashTable<RefPtr<T>> :^)
It's unfortunate about the const_casts. We'll need to fix HashMap::get
to play nice with non-const Traits<T>::PeekType at some point.
This was actually rather painless and straightforward. WindowServer now
runs as the "window" user. Users in the "window" group can connect to
it via the socket in /tmp/portal/window as usual.
We now allocate 64KB at a time and divide them into chunks for handing
out to malloc() callers. This significantly reduces the number of
system calls made due to memory allocation.
This yields a ~15% speedup when compiling Process.cpp inside SerenityOS
(down from 24 sec to 20 sec on my machine.)
There's more performance on the table here, no doubt.
This reverts commit 4e79a60b78.
This broke the GCC port. Apparently isblank() was added in C99 and for
some reason it needs special treatment in headers.
This mechanism wasn't actually used to create any WeakPtr<Process>.
Such pointers would be pretty hard to work with anyway, due to the
multi-step destruction ritual of Process.
A 16-bit refcount is just begging for trouble right nowl.
A 32-bit refcount will be begging for trouble later down the line,
so we'll have to revisit this eventually. :^)
