greg at gregweber.info
Thu Aug 18 16:42:00 CEST 2011
For 1), The previous discussion just concluded that the time to fetch the
date is very small. The advantage of always fetching the date is that you
can remove the need for a separate date thread . I always think of delays
as a code smell and look for other ways of doing things. In this case the
There is no guarantee that the thread will be rescheduled promptly when
the delay has expired, but the thread will never continue to run
And currently the date thread is set to a delay of one second- it is almost
inevitable for it to get time-shifted and then actually end up logging the
wrong second (for a second, not that it would matter a lot too most). The
real issue is that under high load we don't have a guarantee that time will
be updated- if competing against CPU bound threads this implementation would
rely on fair scheduling to get the date updated.
I think the additional complexity of a separate thread should be justified
in a benchmark vs. the simpler solution discussed which Snap now implements
: See how much simpler Snap's logging code is after our discussion:
On Thu, Aug 18, 2011 at 6:47 AM, Michael Snoyman <michael at snoyman.com>wrote:
> On Thu, Aug 18, 2011 at 11:21 AM, Kazu Yamamoto <kazu at iij.ad.jp> wrote:
> > Hello,
> > Sorry for the delay but I have released wai-logger:
> > http://hackage.haskell.org/package/wai-logger
> > I provide low level modules and a high level module. Users should use
> > the low level modules. The high level module is designed for Mighttpd
> > which uses the prefork technique.
> > A sample code is found in its module documentation.
> > Please use this package and give me feedback. And let's consider how
> > to make this as a WAI middle ware.
> > --Kazu
> > _______________________________________________
> > web-devel mailing list
> > web-devel at haskell.org
> > http://www.haskell.org/mailman/listinfo/web-devel
> Looks very good. Two questions:
> 1. I thought the conclusion of the previous discussion was that
> updating the time every second via a thread was less efficient than
> comparing timestamps and updating as necessary.
> 2. Would it make sense to use a Builder (from blaze-builder) in place
> of LogStr? Though based on the black magic you have going on under the
> surface there, I'm guessing you did it this way for a reason ;).
> web-devel mailing list
> web-devel at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the web-devel