din laborator :<br><br>"Sigwait suspendă firul apelant până unul dintre semnalele specificate
în mască este transmis spre firul de execuție respectiv. La revenire
funcția va salva în <i>sig </i>numărul
semnalului primit. <b>Semnalele din mulțimea specificată prin mască
trebuie să fie anterior blocate și nu ignorate la intrarea în <i>sigwait</i></b>.
Dacă semnalul primit are un handler atașat el nu va fi apelat. Pentru
mai multe detalii despre semnale pentru threaduri puteți folosi linkul
de la sfarsit"<br><br>De aici ar rezulta ca trebuie sa facem noi ceva explicit pentru a bloca semnalele asteptate.<br><br>-------------------------------<br><br>din linkul de la sfarsit :<br><br>"<a name="J.4">
J.4: When one thread is blocked in
<code>sigwait()</code>, other threads no longer receive the signals
<code>sigwait()</code> is waiting for! What happens? </a><br><br>
It's an unfortunate consequence of how LinuxThreads implements
<code>sigwait()</code>.<b> Basically, it installs signal handlers on all
signals waited for, in order to record which signal was received.
Since signal handlers are shared with the other threads, this
temporarily deactivates any signal handlers you might have previously
installed on these signals.</b><p>
Though surprising, this behavior actually seems to conform to the
POSIX standard. According to POSIX, <code>sigwait()</code> is
guaranteed to work as expected only if all other threads in the
program block the signals waited for (otherwise, the signals could be
delivered to other threads than the one doing <code>sigwait()</code>,
which would make <code>sigwait()</code> useless). In this particular
case, the problem described in this question does not appear. "</p><br>De aici rezulta ca noi nu trebuie sa facem nimic inainte sa apelam "sigwait", pentru ca functia o sa faca singura blocarea semnalelor pe care le asteapta prin instalarea de handlere dummy pentru ele ...
<br><br>------------------------------<br><br>cum e bine ? ;;)<br>