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.tib...@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@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users