Incrementally consuming the eventlog
donnie at darthik.com
Thu Apr 28 23:53:20 CEST 2011
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
More information about the Glasgow-haskell-users