This is done here rather than pick_new_active_window() so that when
there are no other windows to focus but the previous window hasn't
been removed (just minimized), the menu bar remains on that client.
Also make sure we send out the WM event for window deactivations.
This fixes an issue where the taskbar button for a window would appear
depressed, even after the window was deactivated.
At the moment, addresses below 8MB and above 3GB are never accessible
to userspace, so just reject them without even looking at the current
process's memory regions.
Add an option "-A", that will run all of the crash types in the crash
program. In this mode, all crash tests are run in a child process so
that the crash program does not crash.
Crash uses the return status of the child process to ascertain whether
the crash happened as expected.
This patch hardens /proc a bit by making many things only accessible
to UID 0, and also disallowing access to /proc/PID/ for anyone other
than the UID of that process (and superuser, obviously.)
We were happily allowing syscalls with pointers into kernel-only
regions (virtual address >= 0xc0000000).
This patch fixes that by only considering user regions in the current
process, and also double-checking the Region::is_user_accessible() flag
before approving an access.
Thanks to Fire30 for finding the bug! :^)
Instead of just boosting the main thread, let's boost all threads in
the currently active client process.
This avoids creating internal priority inversion problems in clients.
When the currently active (foreground) window is owned by a client,
we now apply a +10 priority boost to the client's main thread.
You normally want the window you're interacting with to be responsive,
so this little boost allows it to run a bit sooner and more often. :^)
This patch introduces a syscall:
int set_thread_boost(int tid, int amount)
You can use this to add a permanent boost value to the effective thread
priority of any thread with your UID (or any thread in the system if
you are the superuser.)
This is quite crude, but opens up some interesting opportunities. :^)
Threads now have numeric priorities with a base priority in the 1-99
range.
Whenever a runnable thread is *not* scheduled, its effective priority
is incremented by 1. This is tracked in Thread::m_extra_priority.
The effective priority of a thread is m_priority + m_extra_priority.
When a runnable thread *is* scheduled, its m_extra_priority is reset to
zero and the effective priority returns to base.
This means that lower-priority threads will always eventually get
scheduled to run, once its effective priority becomes high enough to
exceed the base priority of threads "above" it.
The previous values for ThreadPriority (Low, Normal and High) are now
replaced as follows:
Low -> 10
Normal -> 30
High -> 50
In other words, it will take 20 ticks for a "Low" priority thread to
get to "Normal" effective priority, and another 20 to reach "High".
This is not perfect, and I've used some quite naive data structures,
but I think the mechanism will allow us to build various new and
interesting optimizations, and we can figure out better data structures
later on. :^)
This removes a bunch of JsonValue copying from the hot path in thread
statistics fetching.
Also pre-size the thread statistics vector since we know the final size
up front. :^)
This variant of get() returns a const JsonValue* instead of a JsonValue
and can be used when you want to peek into a JsonObject's member fields
without making copies.
Instead of using ByteBuffer (which always malloc() their storage) for
IPC message encoding, we now use a Vector<u8, 1024>, which means that
messages smaller than 1 KB avoid heap allocation entirely.
The widget layout system currently works by having layouts size the
children of a widgets. The children then get resize events, giving them
a chance to lay out their own children, etc.
In keeping with this, we need to handle the resize event before calling
do_layout() in a widget, since the resize event handler may do things
that end up affecting the layout, but layout should not affect the
resize event since the event comes from the widget parent, not itself.
If an mmap fails to allocate a region, but the addr passed in was
non-zero, non-fixed mmaps should attempt to allocate at any available
virtual address.
