[haiku-bugs] Re: [Haiku] #8007: [app_server] fully unresponsive when resizing window of big textfile
- From: "axeld" <trac@xxxxxxxxxxxx>
- Date: Thu, 08 Mar 2012 21:51:43 -0000
#8007: [app_server] fully unresponsive when resizing window of big textfile
-----------------------------+----------------------------
Reporter: ttcoder | Owner: axeld
Type: bug | Status: new
Priority: normal | Milestone: R1
Component: System/Kernel | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking: 7882, 8136
Has a Patch: 1 | Platform: All
-----------------------------+----------------------------
Comment (by axeld):
Replying to [comment:42 jua]:
> (btw, would kernel mutexes really be used to signal rare events anyway,
instead of, say, semaphores?)
Not sure what you mean by signaling, but this sounds like a misconception
about what a mutex is. Unlike a semaphore, a mutex is a simple lock. There
is nothing to signal, it's only used to protect critical sections, ie. to
make sure only one thread runs at a time with that particular lock held.
For signaling, condition variables can be used in the kernel, and even
though they are connected to a mutex, you don't hold the lock while you're
waiting for the condition to arise.
Anyway, I had a look at the patch, and apart from like hundreds of coding
style violations, I'm not sure the way it's implemented is how it should
look like; while it should be rare or never happen that a thread acquires
32 different mutexes, imposing such a limit (with no noticeable overflow
handling) is troublesome. An alternative would be to use the same approach
as with the waiters list - that would also speed up the insert, at least.
I would have hoped that bonefish comments on the patch, but apparently he
didn't find the time to do this yet.
A few words on the coding style issues, and a bit more:
* two blank lines between functions.
* we use camelCaseForVariableNames.
* '{' goes to the same line as if/while/etc.
* You mix asterisk style.
* In general, having the code look like the one that is already there is a
good thing to try.
* Things like ASSERT(thread) makes no sense when the function would
immediately crash in that case, anyway (besides that we would write
ASSERT(thread != NULL)).
* Same for asserting that thread_get_current_thread() didn't return NULL.
It can't.
* Comments like "Add the lock we just acquired to the array of held locks
for this thread." right before you call add_lock_to_held_locks() are
superfluous.
* Instead, important comments like "guarded by the scheduler lock" are
missing.
* You sometimes mix KDEBUG code with non-KDEBUG code (like
_mutex_transfer_lock()).
* There is no reason for the static inline mutex_transfer_lock() anymore,
if all it does is calling _mutex_transfer_lock().
* mutex::holder becomes superfluous as well, AFAICT.
--
Ticket URL: <http://dev.haiku-os.org/ticket/8007#comment:48>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
