[haiku-bugs] Re: [Haiku] #8007: [app_server] fully unresponsive when resizing window of big textfile
- From: "bonefish" <trac@xxxxxxxxxxxx>
- Date: Fri, 09 Mar 2012 20:51:51 -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 bonefish):
Replying to [comment:49 jua]:
> Replying to [comment:48 axeld]:
> >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.
I haven't looked at the code yet. However, as far as I can tell from the
comments, I suppose a simple alternative here would be to add a list link
to the mutex structure.
--
Ticket URL: <http://dev.haiku-os.org/ticket/8007#comment:50>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
