| Subject: | patch: syswrite option for Log::Dispatch::File |
https://github.com/karenetheridge/Log-Dispatch/tree/topic/file_syswrite
contains the 'syswrite' option for Log::Dispatch::File that I mentioned
to autarch last month:
--- Log opened Wed Oct 17 13:03:50 2012
13:03 <ether> would you be receptive to a patch to Log::Dispatch::File
to change 'print $fh $string' in log_message to syswrite($fh, $string)?
I see that the former can have problems in multiprocess environments
with text interleaving, because print goes through the stdio library,
rather than directly through the kernel
13:04 <ether> e.g. see the last post at
http://www.perlmonks.org/?node_id=486488
14:18 <autarch> well, there's already a File::Locked output, isn't there?
14:29 <autarch> but I guess I'm not super opposed to the patch you suggest
15:38 <ether> idn't dtrt, it (or me) may be misinterpreting
15:38 <ether> gah
15:38 <ether> let me try again
15:39 <ether> yes. I was looking at
https://metacpan.org/module/Log::Dispatch::FileShared , which suggested
that File::Lock didn't dtrt, but it (or me) may be misinterpreting.
15:39 <autarch> oh right
15:39 <autarch> yeah, that stuff is crufty and old
15:39 <autarch> honestly I just use syslog for everything nowadays
15:39 <ether> my understanding of that perlmonks post is that modern
unix kernels do guarantee that appends will not *clobber* each other,
but depending on the length of the message and the block size in your
filesystem, you may have two messages interleaved, unless you used syswrite
15:39 <autarch> I still use Log::Dispatch so I can to-the-screen
debugging easily
15:40 <ether> do you syslog through Log::Dispatch, or directly?
15:40 <autarch> through LD
15:40 <autarch> so I can use Log::Dispatch::SCreen
15:40 <ether> if I can hook syslog to Log::Contextual then most problems
would be solved (but not this week; critical project has seized all tuits)
15:42 <ether> anyway, aforementioned tuit list just got an item to patch
LD::File to add a syswrite flag (defaulting to off). it's just a few
lines so will be straightforward.
15:42 <ether> I'll think about the problem more though to be sure if I
really want this solution
15:43 <autarch> apparently you can use Log::Dispatchouli with
Log::Contextual
15:44 <autarch> MOAR LAYERS!
15:50 <ether> isn't Log::Dispatchouli simply Log::Dispatch with a bunch
of defaults pre-set for convenience?
15:51 <ether> I've been happily using Log::Dispatch+Log::Contextual for
quite a while now
15:52 <ether> ...along with Plack::Middleware::Log::Contextual,
Plack::Middleware::LogWarn, and Plack::Middleware::LogDispatch
15:52 <ether> oh and Plack::Middleware::HJTTP::^?^?Exceptions too :)
15:52 <autarch> oh, I didn't realize you could use LD + LC (without the
ouli)
15:52 <ether> all of these combined means that stderr goes to
psgix.logger, and psgix.logger goes to Log::Dispatch, and a
Log::Contextual with_logger gets wrapped around the $app
15:52 <ether> yeah it "just works"
15:52 <ether> :D
15:53 <autarch> ugh, I really don't like the psgi logging stuff, it's
just weird
15:53 <autarch> although I can usually beat it into doing what I want