Jay Hoover wrote:
I'm currently investigating a deadlock we're experiencing under high
load in Asterisk and I have a question about hup_handler. I don't yet
have enough information on this or a good enough repro to write up a
report, but it appears to be a deadlock caused by hup_handler calling
into ast_module_reload from a thread that is currently inside a system
call.
Can anyone enlighten me about why ast_module_reload needs to be called
from the SIGHUP handler? I see that this was added quite a few years
ago (may '01), but I can't find anything in the code that explains the
reasoning behind it.
Hmm. Ignoring the SIGHUP vs. asterisk -rx 'reload' issue for now,
looking at hup_handler, it appears to be doing things in exactly the
wrong way - ie. actually calling the reload function from within the
signal handler itself.
The proper way to do this is to use deferred execution - the SIGHUP
handler simply sets a flag, and another thread periodically checks that
flag, and runs ast_module_reload(NULL) if the flag is set.
That way, the complicated code gets run in a known thread/mutex/etc.
context, and deadlocks should be able to be completely avoided.
Considering Asterisk is a multithreaded program, it should probably be
using sigwait(3) instead of signal(2) anyway...
No patch at the moment, sorry ;-)
Cheers,
Nic.
--
Nic Bellamy,
Head Of Engineering, Vadacom Ltd - http://www.vadacom.co.nz/
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
