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

[Jim C. <jc...@di...>]

Mike Schilli wrote:

>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.
>

cool - that was my hope

> > 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.
>  
>

Ok - but it precludes use of alarm to (fully) emulate $delay = 60 
behavior of existing timeout, as it cant reset itself.  Of course, 
theres no 'real' reason to emulate - folks can do it the old way.

> > 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 :).
>  
>

# you should add a
 warn "IM DESTROYING YOUR EXISTING SIGNAL HANDLER ON $sig"
    if $SIG{$sig}
# cuz people are often unaware of the signals used deep in a library or 
a framework.

# and perhaps/maybe give them some (obscure, undocumented) way to shoot 
themselves in the foot. 
$Log::Log4perl::Watcher::stack_handlers = 1;

> > 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?
>  
>
heh  - true true.  your approach borders on paranoid :-) L<perldoc perlipc>

>Anyways, thanks a bunch for your comments!
>
:-)   even half-baked comments are better than silence.  this list is 
low-traffic enough that a little noise is ok.

>
>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%.
>
>  
>
cool ! esp for traditional - where 99% of re-inits have no changes.

btw - when re-init happens, does it just throw away the old init and 
rebuild a brand-new structure ?
the reason I ask is that my AutoCategorize sub-class builds a lot of 
anonymous subs to delegate up
to Log4perl, and it would be nice not to throw out the whole lot.

If both the b4 and after configs are available at some (transient) 
point, and a hook is available so I
can inspect them, I can find the diffs and delete only those subs whose 
config has been superceded.