Incrementally consuming the eventlog

[Don Stewart]

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
supported.

*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.

-- Don

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
> me.
>
> I'm sure Simon M knows better than I do regarding this...
> I look forward to hearing more.  Thanks.
> --
> Donnie
>
> On Thu, Apr 28, 2011 at 4:31 PM, Johan Tibell <johan.tibell at gmail.com> wrote:
>> Hi,
>>
>> 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
>> again.
>> - 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
>> full?
>>
>> Johan
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>