Nested threads

[Johannes Kliemann]

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.

Regards,
Johannes

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 ld-linux.lib.so ld.lib.so
>   gdb ./binary_of_your_component -p <PID-of-your-component>
> 
> Cheers
> Norman
>