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