Hi Johannes, On 01.06.2018 11:38, Johannes Kliemann wrote: > are nested threads (e.g. a thread class that owns an object of another > thread class and starts it from within its entry() method) a special > case? I noticed that the terminal session blocked from the inner thread > (write was called from the thread but the write implementation of the > terminal session was never executed). Putting the inner thread on the > same level as the outer one solved the problem.
I don't know exactly what you mean by "nesting" but I cannot think of anything special when instantiating a 'Thread' object in the context of another thread. By this notion, each thread - in fact, even the initial entrypoint - of a component would be a nested thread then. What you observe looks like some form of deadlock. Are you able to reproduce the problem in a simple scenario on base-linux? If yes, the backtraces of the various threads (obtained by attaching GDB to the PID of your component, see below) would certainly reveal the issue. cd build/x86_64/debug ln -sf ld-linux.lib.so ld.lib.so gdb ./binary_of_your_component -p <PID-of-your-component> Cheers Norman -- Dr.-Ing. Norman Feske Genode Labs https://www.genode-labs.com · https://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth _______________________________________________ Genode users mailing list [email protected] https://lists.genode.org/listinfo/users
