[haiku-development] Re: Lock/Thread private includes problem

Julian Harnath wrote:
> I finally found time to work again on the priority inheritance patch. 
> Now I have a little problem with the Haiku private include files...
> 
> In lock.h I need a definition from thread.h, so I want to include it 
> there -- however, that does not work.
> Reproducing the problem is very simple, just open 
> header/private/kernel/lock.h, insert "#include <thread.h>" in it and try 
> to compile the kernel. It results in a big number of compiler errors.
> 
> I already tried to debug it by looking at preprocessor output (which 
> confuses me because the order of included files in the preprocessed 
> output is not how I expect it), adding other includes and changing 
> include orders, etc... *some* of the errors can be solved that way 
> (although it shouldn't depend on order or other includes anyway), but 
> so far nothing helped and I couldn't find out what actually causes the 
> problem. Can anybody help?

<thread.h> includes <thread_types.h> which in turn includes <lock.h> (since 
locking primitives are used in the thread related structures). So by including 
<thread.h> (or just <thread_types.h>) you get an include cycle. While it is 
sometimes possible to use some trickery to solve issues with cycles, best 
practice is to avoid them altogether.

Often one doesn't actually need to include some header. A "class/struct Foo;" 
suffices when only references or pointers to that structure are used. One 
common situation that makes this strategy impossible are inline functions 
implemented in the header. Those tend to dereference objects or call functions 
declared elsewhere. Both <thread.h> and <lock.h> do that. One solution is not 
to inline problematic functions, which, however, negates the performance 
advantages sought by making them inline in the first place. An alternative -- 
which so far has not been used -- is to move inline functions to a separate 
header. I'd propose "foo_inline.h" for a header "foo.h" and "FooInline.h" for a 
header "Foo.h" as a naming convention. I.e. in this case we'd probably need 
additional headers <thread_inline.h> and <lock_inline.h> (maybe even 
<thread_structs_inline.h>). That change isn't complicated, but it might be 
quite a bit of work, since I guess there are a lot of files that will need to in
 clude the new instead of the original headers afterwards.

CU, Ingo

Other related posts: