On 28/06/06, Gilles Chanteperdrix <[EMAIL PROTECTED]> wrote:
Jan Kiszka wrote:
 > Ok, then we also need a fix for the latency test (this is where I
 > grabbed that pattern from). Is there a high risk that this locks up? I
 > wonder why I never observed or heard of problems with latency.

The latency test used to deadlock, that is why the summary printed on
signal is printed on stderr. Unfortunately, there seem to be one display
left on stdout, so it should still deadlock. The reason why we never see
the deadlock is (perhaps) that the continuous intermediate results are
printed on the context of the "display" thread, whereas the termination
signals are preferably delivered by the kernel to the "main" thread,
that only calls pause. Which makes the use of stderr in signals handlers

It's very likely so.

The main thread would use instead something like :
while (!sig_term_received)

return 0;

cleanup_upon_sig() should only set the sig_term_received flag up.

Then all other threads must block signal delivering with sigprocmask()
so that the main thread is the only one which "accepts" signals.

btw, according to POSIX 1003.1-2003, the write() call is amongst "safe" ones.

So write(1, ....); heh... not that nice? :)

Best regards,
Dmitry Adamushko

Xenomai-core mailing list

Reply via email to