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