[haiku-bugs] Re: [Haiku] #8007: [app_server] fully unresponsive when resizing window of big textfile
- From: "jua" <trac@xxxxxxxxxxxx>
- Date: Tue, 15 May 2012 21:17:21 -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: 0 | Platform: All
-----------------------------+----------------------------
Comment (by jua):
After finally finding time again to work on this, I recently mostly
rewrote the whole thing taking into account the various comments given
here and also made many other enhancements, fixes, etc. But now I'm stuck
and unsure if I can finish it.
The problem is the following:
* To implement the priority inheritance properly while keeping the mutex
functions inline, I need access to functions/types from thread.h and
thread_types.h within lock.h. This created a cyclic include file
dependency. As advised by Ingo on the mailing list, I could resolve the
problem by splitting some include files, moving the inline functions to a
separate file. Most notably, I split lock.h into lock.h / lock_inline.h
and thread_types.h into thread_types.h / thread_types_inline.h. This
solved the dependency issue and let me finish the work inside the kernel.
* The kernel mutexes are used in many places, and in all these places I
need to add "#include <lock_inline.h>" now. This mostly works fine, but in
a few places it causes big trouble... those places are outside the kernel
itself i.e. in kernel add-ons. Including lock_inline.h leads to the
following include-file chain: lock_inline.h -> thread.h -> thread_types.h
-> ksignal.h
* ksignal.h defines struct QueuedSignalsCounter which inherits from class
BReferenceable. The fact that the latter is a class is the problem: some
kernel add-ons (such as the fat file system add-on or locked_pool) are C
and fail to compile when they see the class definition. Trying to tell gcc
to just compile them as C++ leads to various ANSI C++ violations, and even
setting -fpermissive to demote those errors to warnings leaves linker
problems with things defined as extern C.
* So in the end, my changes force everything that uses kernel mutexes to
be compiled as C++ because thread.h requires that. Several add-ons don't
compile as C++.
What could the solutions be? I currently see:
* Change add-ons to be C++-compilable. I'm afraid I couldn't do that, or
at least that would take me a ''long'' time because I don't want to do
changes without really understanding the sources I edit, and it might be
many add-ons... Also, maybe there are add-ons where this is not possible
at all?
* Make mutex functions non-inline. This would have a performance impact on
the whole system.
The priority inheritance simply creates a closer tie between mutexes and
threads, and thus using thread functionality inside the mutex_* inline
functions becomes necessary. It's a little sad that it seems I have to
stop here after putting a lot of work into it, but it seems to not work
out without deeper changes in many parts.
--
Ticket URL: <http://dev.haiku-os.org/ticket/8007#comment:59>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
