Hi Peter,
So what i'm currently trying to do is that i'm trying to have a thread, whose purpose is to initialize some more genode threads as it results in the page faults for some reason. It seems that Genode doesn't like me creating and starting thread instances by another thread (ie. main creates thread1 -> thread1 creates thread2), which I find weird if in actual fact that this actually is not meant to work. I created and started an instance of thread2 in the main function of my genode server, which resulted in that thread working, whereas creating and starting an instance of thread2 in thread1 does not seem to work. I have a question that may contribute to me coming up with a workaround to this problem.
creating threads from other threads should work as expected. Your observation that thread creation from the main thread works but not from any another thread suggests that your creator thread has a too small stack. By default, the main thread has a pretty large stack (64K) but for custom created threads, the typical stack size supplied as template argument to the 'Thread' template is much smaller, in most cases 4K or 8K. So could you try increasing the stack size to 64K for your custom threads?
BTW, because this is a recurring problem, we currently investigate changing the stack allocation such that stack overflows can be easily detected and never corrupt data.
Given that a thread may call a function that belongs to another class, is there any way for me to obtain the ID of the thread that is currently executing? In previous builds of OKL4, L4_Myself() could be used within a function which would return the ID of the thread that was executing when the given function executes.
In OKL4 2.1 there is no such system call. However, Genode provides a way to do it anyway (using a special thread-bootstap protocol). By calling the static member function 'Thread_base::myself()', the caller can obtain its own 'Thread_base' object. This way, you can get the physical thread ID using the 'tid()' accessor. Or even better, you can cast the returned pointer to the specific thread class access the corresponding context.
However, in general, I recommend not relying on this thread-local storage (TLS) mechanism but rather pass the needed context as a pointer to the code that needs to access it. According to our experience, TLS is never needed when developing new code - you can always pass the context to functions as argument. Our solely reason to introduce 'myself()' was the need to reuse existing code (Linux driver, Qt), which already relied on TLS. That said, I'd like to encourage you to look again at your design to see if TLS is really a necessity. In my opinion, avoiding the use of TLS yields to much better code.
Norman