#
1b333570 |
|
28-Jul-2019 |
Augustin Cavalier <waddlesplash@gmail.com> |
app_server: Use RW_LOCK_FLAG_CLONE_NAME in MultiLocker. This behavior was always used by the semaphore-based MultiLocker, and it seems a good chunk of code depends on this, so we need to preserve the behavior.
|
#
fd97a8c7 |
|
27-Jul-2019 |
Augustin Cavalier <waddlesplash@gmail.com> |
app_server: Use a rw_lock instead of 3 (!) semaphores for MultiLocker. Since every HWInterface is a MultiLocker, and every BBitmap requires a server-side BitmapHWInterface, this saves 3 semaphores per BBitmap instance (as well as a lot of semaphore-related overhead in calling the kernel so often.)
|
#
f9c77b11 |
|
27-Jul-2019 |
Augustin Cavalier <waddlesplash@gmail.com> |
app_server: Clean up MultiLocker::IsWriteLocked(). This function was (or at least now is) severely over-engineered: it is designed to avoid calling find_thread(NULL) as little as possible, and use stack addresses to determine if the current thread is the one holding the write lock. However, this is unneccessary, as find_thread(NULL) has been optimized (on x86 and x86_64, at least) to be a single "mov" from thread-local data, with no syscall. So that is probably even faster than an integer divide and compare, allowing this function to be simplified greatly.
|
#
3fed1a15 |
|
05-Aug-2012 |
Alex Smith <alex@alex-smith.me.uk> |
Get app_server working on x86_64. With this commit, app_server now compiles and runs at boot! Nothing particularly interesting happens, just the blue background and a mouse pointer. Remote backends are broken and not compiled in, see #8834. Note that it won't be possible to build this quite yet, need to get the FreeType package uploaded.
|
#
de68adf6 |
|
08-Mar-2011 |
Stephan Aßmus <superstippi@gmx.de> |
Secure coding, sprintf->snprintf. CID 6321. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40881 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
f242acd5 |
|
24-Aug-2010 |
Stephan Aßmus <superstippi@gmx.de> |
Fixed a race condition in MultiLocker, when compiled in DEBUG mode: The fWriterThread and fWriterStackBase were reset in WriteUnlock() without holding any lock. While running a DEBUG compile of app_server, I ran repeatedly into an assertion in the mouse event thread, that it was not the write lock holder anymore when calling WriteUnlock(). My theory (also discussed with Axel, thanks!) is as this: Some random thread holds the write-lock. The mouse event thread is allowed to run when that thread releases the write-lock, but the thread is rescheduled before it resets the write-lock-holder values (B_DO_NOT_RESCHEDULE only means rescheduling is not forced, but it may happen anyway). Then the mouse thread runs, acquires the write-lock, sometime later the original thread continues to run, and completes WriteUnlock() with resetting the holder values. When the mouse thread continues to run and eventually calls WriteUnlock(), the holder values do not match anymore. The theory is further confirmed by the fact, that fWriterThread was always -1 in the assert and not some random other thread. As mentioned, only affected DEBUG builds of app_server, in release builds, another lock protects the holder values. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38331 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
ab45ec86 |
|
18-Aug-2010 |
Stephan Aßmus <superstippi@gmx.de> |
More helpful debugger message. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38239 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
8b56f14a |
|
12-Mar-2010 |
Stephan Aßmus <superstippi@gmx.de> |
Fixed debug build. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35820 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
c79e9de0 |
|
02-Apr-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* Fixed build in DEBUG mode. * Automatic whitespace cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29858 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
4d1c4228 |
|
02-Oct-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* added a way for the ServerWindow message loop to determine the required type of locking before processing the message (single/all window lock) -> in most message cases, I could comment out the unlocking/locking which switched to the different lock, because the required lock is now already held, this removes some race conditions which were commented in the code already * EventDispatcher::SetDragMessage() didn't lock the object, this would have been bad if multiple windows tried to set a drag bitmap at once * the Desktop object keeps track of mouse position and pressed buttons, so that it doesn't need to lock the EventDispatcher for sending fake mouse moves to windows on show/hide of windows (solves some cases of possible dead locks with the new locking strategy) * the keyboard EventFilter switches the current workspace asynchrnously from the Desktop thread (another source of possible deadlocks) * the "reader is trying to become writer" check in MultiLocker is only used in DEBUG mode now As a summary: It would be nice if ServerWindow used a readlock for all messages it processes itself, and forwards all messages for which it needs a write lock to the Desktop thread. All cases where either the Desktop or the ServerWindow mess with the EventDispatcher are possible sources of deadlocks. This is solved right now by making sure that the lock is released before using the EventDispatcher. I have not observed any deadlocks while switching workspaces and launching many apps anymore, neither crashes. But I have not tested extensively except for in the test environment. That being said, I could reproduce the problems on first try before in Haiku. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22410 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
4d1fd46c |
|
02-Feb-2007 |
Axel Dörfler <axeld@pinc-software.de> |
* Replaced DEBUG MultiLocker with an implementation that actually helps debugging locking problems (instead of debugging the locker class). * MultiLocker::IsReadLocked() is now only exported with DEBUG mode turned on, as it only works correctly in this case. * Made MultiLocker safe against B_INTERRUPTED, ie. it now just tries to lock again instead of failing for no obvious reason. * Removed bogus arguments to acquire_sem_etc() in MultiLocker (like B_DO_NOT_RESCHEDULE). * Applied coding style to MultiLocker. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20055 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
2ba6b3a6 |
|
15-Dec-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* minor cleanup git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19526 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
39c9925f |
|
07-Apr-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* implemented a BRegion pool per WindowLayer which is supposed to cut down on BRegion related allocations, cannot really tell if it speeds things up * used the new BRegion pool in WindowLayer and ViewLayer whereever a BRegion was used on the stack * fixed the debugging stuff in MultiLocker - it will get you into the debugger if you - try to nest read locks - try to write lock when your are a reader already - don't match up nested locks when your a writer -> but only if you #define DEBUG 1 in the .cpp, is off by default now * went over WindowLayer, ServerWindow, Desktop and a few other places and fixed the locking for use with the MultiLocker, the "a reader can not become a writer" is especially tricky, feel free to review the changes * activated the MultiLocker, I tested this quite a bit, if there are problems simply turn on DEBUG and you should drop into the debugger right where the problem is... hope all is good git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17046 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
f7598223 |
|
18-Nov-2005 |
Axel Dörfler <axeld@pinc-software.de> |
* the new input event dispatcher is now actually used, although it doesn't distribute any messages to the clients yet. * removed the working thread from RootLayer - for now, its event handlers are still called using input filters in the new event dispatcher, though (to get things started). * ServerApp is now using a BMessenger to identify its client, and no longer stores the port/token separately. * the input_server handshake is a bit simpler now, as it can now just reply to the app_server message, removed unused code from ServerProtocol.h * calmed down the MultiLocker (it always printed thread statistics on startup, because it's compiled in debug mode). * removed the cursor thread stuff from AppServer.cpp * the new event dispatcher now uses a cursor thread when supported (only in native mode, not in the test environment), although it improves cursor movement under Qemu, the effect is not as good as expected - this might need some more investigations (might just be a thread priority problem). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15012 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
f38c001e |
|
04-Nov-2005 |
Marcus Overhagen <marcusoverhagen@gmail.com> |
Assigned names to "some BLocker"s to aid debugging. Small cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14703 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
3dcb3b07 |
|
23-Jun-2005 |
Stephan Aßmus <superstippi@gmx.de> |
Added some root layer locking in ServerWindow.cpp when accessing the layer tree. Moved HWInterface management out of DisplayDriverPainter and into Desktop. Removed all the directly hardware related functions from DisplayDriver API. They just called the same HWInterface functions. Now DisplayDriver is much cleaner and ready for being attached to a yet to be written BitmapHWInterface. Clean up of the display mode stuff in Screen and the View-/AccelerantHWInterface. Frequency is now regarded on Haiku. AccelerantHWInterface::GetModeList now works before SetMode has been called. Added MultiLocker from the sample code. HWInterface uses it now in preparation to being used from multiple instances of DisplayDriver. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13252 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
3fed1a15f58e8d6fe6b492f3b94bb3625ffeddbd |
|
05-Aug-2012 |
Alex Smith <alex@alex-smith.me.uk> |
Get app_server working on x86_64. With this commit, app_server now compiles and runs at boot! Nothing particularly interesting happens, just the blue background and a mouse pointer. Remote backends are broken and not compiled in, see #8834. Note that it won't be possible to build this quite yet, need to get the FreeType package uploaded.
|
#
de68adf69b9533652715b9bba3ec07ecd3ea5811 |
|
08-Mar-2011 |
Stephan Aßmus <superstippi@gmx.de> |
Secure coding, sprintf->snprintf. CID 6321. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40881 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
f242acd5a09972a96fa32238196c0fcf89abada4 |
|
24-Aug-2010 |
Stephan Aßmus <superstippi@gmx.de> |
Fixed a race condition in MultiLocker, when compiled in DEBUG mode: The fWriterThread and fWriterStackBase were reset in WriteUnlock() without holding any lock. While running a DEBUG compile of app_server, I ran repeatedly into an assertion in the mouse event thread, that it was not the write lock holder anymore when calling WriteUnlock(). My theory (also discussed with Axel, thanks!) is as this: Some random thread holds the write-lock. The mouse event thread is allowed to run when that thread releases the write-lock, but the thread is rescheduled before it resets the write-lock-holder values (B_DO_NOT_RESCHEDULE only means rescheduling is not forced, but it may happen anyway). Then the mouse thread runs, acquires the write-lock, sometime later the original thread continues to run, and completes WriteUnlock() with resetting the holder values. When the mouse thread continues to run and eventually calls WriteUnlock(), the holder values do not match anymore. The theory is further confirmed by the fact, that fWriterThread was always -1 in the assert and not some random other thread. As mentioned, only affected DEBUG builds of app_server, in release builds, another lock protects the holder values. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38331 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
ab45ec86ab1abfe19ac5bca871f65804df123912 |
|
18-Aug-2010 |
Stephan Aßmus <superstippi@gmx.de> |
More helpful debugger message. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38239 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
8b56f14aeba18bc3cea7e8f12708c7b155b374fa |
|
12-Mar-2010 |
Stephan Aßmus <superstippi@gmx.de> |
Fixed debug build. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35820 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
c79e9de0f60413fb46582e53ac36bc4ca8a60652 |
|
02-Apr-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* Fixed build in DEBUG mode. * Automatic whitespace cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29858 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
4d1c4228028075b8982d13c645cd206a28419df7 |
|
02-Oct-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* added a way for the ServerWindow message loop to determine the required type of locking before processing the message (single/all window lock) -> in most message cases, I could comment out the unlocking/locking which switched to the different lock, because the required lock is now already held, this removes some race conditions which were commented in the code already * EventDispatcher::SetDragMessage() didn't lock the object, this would have been bad if multiple windows tried to set a drag bitmap at once * the Desktop object keeps track of mouse position and pressed buttons, so that it doesn't need to lock the EventDispatcher for sending fake mouse moves to windows on show/hide of windows (solves some cases of possible dead locks with the new locking strategy) * the keyboard EventFilter switches the current workspace asynchrnously from the Desktop thread (another source of possible deadlocks) * the "reader is trying to become writer" check in MultiLocker is only used in DEBUG mode now As a summary: It would be nice if ServerWindow used a readlock for all messages it processes itself, and forwards all messages for which it needs a write lock to the Desktop thread. All cases where either the Desktop or the ServerWindow mess with the EventDispatcher are possible sources of deadlocks. This is solved right now by making sure that the lock is released before using the EventDispatcher. I have not observed any deadlocks while switching workspaces and launching many apps anymore, neither crashes. But I have not tested extensively except for in the test environment. That being said, I could reproduce the problems on first try before in Haiku. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22410 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
4d1fd46cdf49413c13bf55d392d5315457f3aa68 |
|
02-Feb-2007 |
Axel Dörfler <axeld@pinc-software.de> |
* Replaced DEBUG MultiLocker with an implementation that actually helps debugging locking problems (instead of debugging the locker class). * MultiLocker::IsReadLocked() is now only exported with DEBUG mode turned on, as it only works correctly in this case. * Made MultiLocker safe against B_INTERRUPTED, ie. it now just tries to lock again instead of failing for no obvious reason. * Removed bogus arguments to acquire_sem_etc() in MultiLocker (like B_DO_NOT_RESCHEDULE). * Applied coding style to MultiLocker. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20055 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
2ba6b3a649d9fc638fd9a24461264ee3855afef6 |
|
15-Dec-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* minor cleanup git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19526 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
39c9925fcf718dbb8c8d5342997d6bbd40f9e7e4 |
|
07-Apr-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* implemented a BRegion pool per WindowLayer which is supposed to cut down on BRegion related allocations, cannot really tell if it speeds things up * used the new BRegion pool in WindowLayer and ViewLayer whereever a BRegion was used on the stack * fixed the debugging stuff in MultiLocker - it will get you into the debugger if you - try to nest read locks - try to write lock when your are a reader already - don't match up nested locks when your a writer -> but only if you #define DEBUG 1 in the .cpp, is off by default now * went over WindowLayer, ServerWindow, Desktop and a few other places and fixed the locking for use with the MultiLocker, the "a reader can not become a writer" is especially tricky, feel free to review the changes * activated the MultiLocker, I tested this quite a bit, if there are problems simply turn on DEBUG and you should drop into the debugger right where the problem is... hope all is good git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17046 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
f7598223274c44c551f1ed581030e6ed5268fe68 |
|
18-Nov-2005 |
Axel Dörfler <axeld@pinc-software.de> |
* the new input event dispatcher is now actually used, although it doesn't distribute any messages to the clients yet. * removed the working thread from RootLayer - for now, its event handlers are still called using input filters in the new event dispatcher, though (to get things started). * ServerApp is now using a BMessenger to identify its client, and no longer stores the port/token separately. * the input_server handshake is a bit simpler now, as it can now just reply to the app_server message, removed unused code from ServerProtocol.h * calmed down the MultiLocker (it always printed thread statistics on startup, because it's compiled in debug mode). * removed the cursor thread stuff from AppServer.cpp * the new event dispatcher now uses a cursor thread when supported (only in native mode, not in the test environment), although it improves cursor movement under Qemu, the effect is not as good as expected - this might need some more investigations (might just be a thread priority problem). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15012 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
f38c001e5661d4664cf31ea429ef1bc7f87e7dd0 |
|
04-Nov-2005 |
Marcus Overhagen <marcusoverhagen@gmail.com> |
Assigned names to "some BLocker"s to aid debugging. Small cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14703 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
3dcb3b079ab645a90859eba6505cf2692c291138 |
|
23-Jun-2005 |
Stephan Aßmus <superstippi@gmx.de> |
Added some root layer locking in ServerWindow.cpp when accessing the layer tree. Moved HWInterface management out of DisplayDriverPainter and into Desktop. Removed all the directly hardware related functions from DisplayDriver API. They just called the same HWInterface functions. Now DisplayDriver is much cleaner and ready for being attached to a yet to be written BitmapHWInterface. Clean up of the display mode stuff in Screen and the View-/AccelerantHWInterface. Frequency is now regarded on Haiku. AccelerantHWInterface::GetModeList now works before SetMode has been called. Added MultiLocker from the sample code. HWInterface uses it now in preparation to being used from multiple instances of DisplayDriver. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13252 a95241bf-73f2-0310-859d-f6bbb57e9c96
|