Incrementally consuming the eventlog

[Donnie Jones]

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
>