Hi
Of course, that should be
my $main_tid = threads->tid;
sub propagate_hup {
if (threads->tid == $main_tid) {
for my $t (threads->list) { $t->kill('HUP') unless $t->tid ==
$main_tid; }
}
return 1;
}
Regards, John
-
Mike, all,
> A simple fix is:
>
> Log::Log4perl->init_and_watch("dllog.conf", 'HUP',
>{preinit_callback => \&propagate_hup} );
> sub propagate_hup {
>for my $t (threads->list) { $t->kill('HUP'); }
>return 1;
> }
A little too simple upon reflection; I don't
Mike
> Can you provide code to reproduce the problem? I'd be happy to track it
> down.
I haven't been able to reproduce the strife I was having; most use of
signals was failing.
However, there is the obvious. My perl 5.10 is delivering all OS
signals to the 'main' thread, so the logger in it ge
Mike
> Got it, ... , it'll roll out with the next release (1.20).
Thank you!
> By the way, have you tried using the 'syswrite' option of the file
> appender instead? It prevents overlapping messages as well and it's
> easier to use than the synchronizing appender:
>
>log4perl.appender.Logfil
Mike Schilli said:
> It would be great if you could provide test results / bug reports of
> running Log4perl with Perl threads, though.
>
> That being said, there are synchronization mechanisms for file
> appenders:
>
> http://log4perl.sourceforge.net/d/Log/Log4perl/FAQ.html#23804
I've tried usin
Bill Moseley got "Wide character in" errors.
I encountered this a few days ago. I've found it hard to reproduce.
It seems perl has a "Don't ask, don't tell" attitude, but once you've
got the utf8 bit set on some data then it worries about it thereafter.
The ".utf8 = 1" directive only works for t
