[haiku-bugs] Re: [Haiku] #8007: [app_server] fully unresponsive when resizing window of big textfile
- From: "jua" <trac@xxxxxxxxxxxx>
- Date: Thu, 08 Mar 2012 22:21:27 -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 jua):
Replying to [comment:48 axeld]:
> Anyway, I had a look at the patch
Thanks a lot for taking the time!
> apart from like hundreds of coding style violations
Hmh, I'm surprised how many style violations I still made even after
trying to ensure I didn't. Looks like my "regular" coding style I've used
for so long time still crept through, which explains the mix of styles...
sorry. I will fix that, thanks for pointing out details.
>Not sure what you mean by signaling, but this sounds like a misconception
about what a mutex is.
I'm well aware what a mutex is, however, even a mutex can be (mis)used to
"signal" another thread (i.e. by releasing it when knowing the other
thread is waiting for it). I probably misunderstood tqh's comment, it
sounded to me as if mutexes in the kernel would possibly be used in that
way; it's good that they are not.
>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
This limitation was born out of necessity. I first wanted to implement it
by using a list, like you propose, but then quickly ran into a simple
problem: I could not allocate (heap) memory for new list items from within
mutex_lock. Maybe I overlooked something, but all flavours of malloc I
found need to lock a mutex themselves... and then mutex_lock calls malloc
which calls mutex_lock which calls malloc etc... (and before it goes
towards infinity, it quickly crashes with a double lock acquire). It would
need a special malloc that can work without a normal kernel mutex. If
there is anything like that, I didn't find it. And without using malloc, a
fixed size array seemed to be the only sane option.
About overflow handling: it is there, however possibly too simple (?). If
more than 32 mutexes are acquired, they simply don't get added to the
array anymore. I.e. for priority boosting they will be ignored. It will
not crash or fail in any way, the additional mutexes will simply not be
regarded when selecting a potential new boost priority. However, this of
course imposes the restriction that the array of held locks is not used
for anything else in the kernel that might require a complete list.
--
Ticket URL: <http://dev.haiku-os.org/ticket/8007#comment:49>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
