Hi all,
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.
Regards, Johannes
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
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
-
Johannes Kliemann -
Norman Feske