Incrementally consuming the eventlog

Donnie Jones donnie at
Thu Apr 28 23:53:20 CEST 2011

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

More information about the Glasgow-haskell-users mailing list