Incrementally consuming the eventlog
dons00 at gmail.com
Fri Apr 29 00:00:41 CEST 2011
I'm very interested in what the best way to get incremental event data
from a running GHC process would be.
Looking at the code, we flush the event buffer fairly regularly, but
the event parser is currently strict.
So we'd need a lazy (or incremental) parser, that'll return a list of
successful event parses, then block. I suspect this mode would be
*My evil plan is to write a little monitoring web app that just
attaches to the event stream and renders it in a useful "heartbeat"
format* , but I need incremental parsing.
On Thu, Apr 28, 2011 at 2:53 PM, Donnie Jones <donnie at darthik.com> wrote:
> Hello Johan,
> I did the initial implementation of GHC.Eventlog. Sadly, I haven't
> had time to work on it since starting a full-time job after
> university. That being said, I am still interested in GHC and the
> improvement of GHC.Eventlog. Hopefully soon, I will have the time to
> do more development on GHC... hopefully. ;)
> Anyway, from your description, I don't understand how a listener would
> consume the eventlog incrementally?
> I do think it would be useful to register listeners for events. I do
> not think the invocation of a callback would be too much overhead,
> rather the action the callback performs could be a very significant
> overhead, such as sending eventlog data over a network connection.
> But, if you are willing to accept the performance loss from the
> callback's action to gain the event data then it seems worthwhile to
> I'm sure Simon M knows better than I do regarding this...
> I look forward to hearing more. Thanks.
> On Thu, Apr 28, 2011 at 4:31 PM, Johan Tibell <johan.tibell at gmail.com> wrote:
>> We were discussing how to consume the eventlog incrementally on #ghc
>> today. Would it be feasible to offer an API (e.g. GHC.EventLog) that
>> allows programs to register for events that occur in the program?
>> Programs would register listeners like so:
>> registerEventListener (\ event -> doSomethingWith event)
>> The current write-to-file system could be implemented in terms of this
>> API. We could even allow event logging to be turned on/off from within
>> the application, allowing developers to attach to a running
>> application, enable event logging, diagnose the app, and then turn of
>> event logging again.
>> The RTS would invoke listeners every time a new event is written. This
>> design has many benefits:
>> - We don't need to introduce the serialization, deserialization, and
>> I/O overhead of first writing the eventlog to file and then parsing it
>> - Programs could monitor themselves and provide debug output (e.g. via
>> some UI component).
>> - Users could write code that redirects the output elsewhere e.g. to a
>> socket for remote monitoring.
>> Would invoking a callback on each event add too big of an overhead?
>> How about invoking the callback once every time the event buffer is
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
More information about the Glasgow-haskell-users