event-log/live-monitoring.md

@@ -85,7 +85,7 @@ Foo is an abstraction / library (or libraries) that will use the new API of RTS
 - RTS broadcasts on demand once a client connects
 - Sockets seem to be appropriate for live monitoring 
 
-### 09/07/2014
+### 09/07/2014 (Duncan)
 
 - Start/stop of streaming is different from the "sync events" mentioned in goals
 - The details for the middleware library (Foo) are not that relevant now, focus should be on RTS level
@@ -104,6 +104,46 @@ Foo is an abstraction / library (or libraries) that will use the new API of RTS
   - includes/rts/EventLogFormat.h
   - [EventLog](event-log).{h, c}
 
+### 25/07/14 (Peter)
+
+- Stop HECs for sync: Could request a global GC for this? That gives you RTS-wide synchronization for free, and doing a GC is probably (?) cheap enough.
+- Random thought: The "tracing" / "eventlog" split feels like a bit of a relic. Maybe we could now replace the tracing back-end that reads the event-log via socket and produces the old tracing messages? Probably out of scope for you, but this is where we might be going at some point.
+- enableEvents needs room for arguments as well as "flags". Context (edited for brevity):
+
+  ```wiki
+  kvelicka:
+  - enableEvents / disableEvents: Don't want to make it more complicated than it needs to be, but for profiling I would have a good couple of different configurations, not even counting configurable sampling delays. Is there a strong reason that we need to make the interface a bit map? Also - wouldn't it be make more sense if the consumer could decide what messages it wants to receive?
+  are you suggesting that there's no reason for this currently? or is it something about bit vectors specifically that you don't like?
+
+  petermw:
+  Hm, maybe the other way around - what was the intended use for those functions? We are talking essentially about "+RTS -ls", right?
+  So the idea here is that this RTS option calls these functions, and then does what?
+  Suppresses the messages? Wouldn't it be easier to make sure the messages aren't generated in the first place?
+  Bottom line is maybe that I'm a bit confused why this is in the interface to begin with. Only reason I could think of is that you intended to have a central place to change these settings at run-time :)
+
+  kvelicka:
+  having everything in one place makes it easier to run the thing, especially if you want to change the event logger settings on the same running program
+
+  petermw:
+  https://github.com/scpmw/ghc/blob/profiling-ncg/rts/RtsFlags.c#L1657
+  This is what reads these flags currently
+  So the idea here is that instead of, say, "RtsFlags.TraceFlags.scheduler = rtsTrue" we compose some sort of bitmap, then pass it to the eventlog, which presumably unpacks it and sets the very same flag? :)
+  Well, for my profiling I have options like "-Ey100000"
+  Which would activate generation of cycle sampling messages with a period of 100000 cycles
+  That's not something that would fit into a simple "on/off" scheme
+  It's a flag with arguments essentially. I would like something along the lines of enableEvents(type, param, ...) and disableEvents(type) more
+  The "full" parameterisation here would be enableEvents(ET_SAMPLES, SAMPLE_INSTRUCTION_POINTER, SAMPLE_BY_SAMPLES, 100000);
+  Because theoretically we might also sample by cost-centres - and I probably wouldn't want another "type" for every single performance metric that perf_events offers
+  ```
+- Event should hold its parent Capability in itself, having CapEvents is redundant (may be out of scope for my project)
+- Headers are not used by users of ghc-events 
+
+
+Possible solutions to remove EventBlock: 
+
+- Yeah, the easiest implementation would be IORef (Seq CapEvent), or something along those lines
+- Maybe IORef \[CapEvent\] is enough as well
+
 ## Discussed APIs