[asterisk-dev] Question about hup_handler & deadlocks

[Nic Bellamy]

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/