Nested threads

Johannes Kliemann kliemann at
Tue Jun 19 15:38:13 CEST 2018

Hi Norman,

thank you for your hints. I could fix the problem which was caused by a
blocking call on a libc function without using Libc::with_libc.
Correctly encapsulating the affected code solved the problem.


Am 09.06.2018 um 10:37 schrieb Norman Feske:
> 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
>   gdb ./binary_of_your_component -p <PID-of-your-component>
> Cheers
> Norman

More information about the users mailing list