[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
 * Instead, important comments like "guarded by the scheduler lock" are
 * You sometimes mix KDEBUG code with non-KDEBUG code (like
 * 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: