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