Re: [log4perl-devel] Config file reload on signal

[Mike S. <msc...@ao...>]

Jim Cromie wrote:

 > does patch allow user to use ALRM to duplicate existing behavior.
 > consistency would dictate that this is a good idea.

Interesting idea, I've just tested it with setting the signal to 'ALRM' 
and triggering it via alarm(1). Works.

 > new() sets the signal handler itself, its probly prudent to document
 > this IN LARGE LETTERS.

I've added some documentation to both Log4perl.pm (about performance) 
and Watch.pm (about the new signal handler), thanks for the reminder :).

 > also, since the handler is set there, theres no opportunity to restart
 > the alarm.

That should be up to the application. By calling alarm(0), the alarm 
will be reset. Should be independant of Watch.pm.

 > any point to saving prior signal handler, and maybe even calling it
 > after setting SIGNAL_CAUGHT ?

Hmm, you mean what happens if there's already a signal handler defined? 
It'll be brutally overwritten, hopefully the new doc in Watch.pm 
illustrates that. I don't want to get into the business of calling other 
people's signal handlers :).

 > also FWIW - 5.8.0 has safe signals by default, earlier doesnt.  there
 > may be some suprises in there.

The design allows for all kinds of hickups -- all the handler does is 
set a global variable. It either does it or the signal gets lost. If it 
does, Log4perl gets re-initialized, if it gets lost, it doesn't. Can you 
think of anything more severe?

Anyways, thanks a bunch for your comments!

Oh, by the way, I found something in the watcher code: By delaying 
getting the $logger and $level parameters from the stack until they're 
actually needed, the 'SIG' watch enabled code now holds up to 90% of the 
full init() speed for suppressed logger calls! This also helped the 
traditional init_and_watch, which is now at about 60%.

-- 
-- Mike
Mike Schilli
msc...@ao...
AOL Unified Preferences Engineering