Wow. This was exactly the kind of thing I was hunting for ages...
So a simple warning(0, "SIGHUP received, catching and re-
opening logs");
was killing it...
Thanks a lot...
On 17.04.2007, at 14:20, Raul Igrisan wrote:
I was not able to reproduce the hang by running the code you’ve
mentioned UNTIL I hit it with
for ((;1;)); do kill -s SIGHUP 12374; done;
from another console.
It hung and DDD clearly showed why:
SIGHUP was delivered to the main thread(1) which became alertable
during executing warning(...), after it managed to add a producer
and hung trying to reacquire the permanent lock when called warning
(...) again.
But the lock was held by ThreadC (3) waiting for the producer to be
removed.
Now every thread calling debug/warning/ etc will hang.
You may avoid this by not calling gwlib directly from the signal
handler (by setting a flag for example).
The pthreads mutex functions are not async signal safe anyway and
are not to be called from signal handlers.
From: Andreas Fink [mailto:[EMAIL PROTECTED]
Sent: 17 April 2007 03:26
To: Raul Igrisan
Cc: 'devel Devel'
Subject: Re: Race condition in list_consume()
I can now easily reproduce the problem with the attached code. It
will run for a few seconds and then deadlock.
<ThreadC(3).JPG>
<MainThread(1).JPG>
Andreas Fink
Fink Consulting GmbH
Global Networks Schweiz AG
BebbiCell AG
---------------------------------------------------------------
Tel: +41-61-6666330 Fax: +41-61-6666331 Mobile: +41-79-2457333
Address: Clarastrasse 3, 4058 Basel, Switzerland
E-Mail: [EMAIL PROTECTED]
www.finkconsulting.com www.global-networks.ch www.bebbicell.ch
---------------------------------------------------------------
ICQ: 8239353 MSN: [EMAIL PROTECTED] AIM: smsrelay Skype: andreasfink
Yahoo: finkconsulting SMS: +41792457333
