On Mon, Jan 29, 2018 at 11:00 AM, Robin Sommer <ro...@icir.org> wrote:
> as you point out, that wouldn't solve inter-event dependencies. > Per Jan's mail, one can work around that with custom code The inter-event dependencies + code understandability/readability issue that Johanna points out is maybe something that would also bother me if it weren't addressed. And taking Jan's idea a bit further, if we had more complete coroutine/yield support in scripts you could write: event protocol_event_1(...) { c$proto$la = function_call; } event protocol_event_end(...) { yield WaitForProtoFields(); Log::write([....c$proto$la...]); } There, WaitForProtoFields() would be an arbitrary/custom function you write. E.g. return false unless all fields of c$proto have been set. So here, maybe the code is more readable because the depender is now explicit about their dependencies. Though I think it's still problematic to know when to write that code because you would still have to rely on either memory (or documentation) to tell you that 'function_call' is actually not synchronous. And if 'function_call' starts as a synchronous function and later changes, that's also kind of a problem, so you might see people cautiously implementing the same type of code patterns everywhere even if not required for some cases. > Actually, I think one > possible solution has been floating around for a while already: event > *scopes* that express serialization requirements in terms of shared > context. Most common example: serialize all events that are triggered > by the same connection. Originally this came up in the context of > running event handlers concurrently. I believe it would solve this > problem here too: when a function suspends, halt all handlers that > depend on the same context (e.g., same connection). More on that idea > in this paper: http://www.icir.org/robin/papers/ccs14-concurrency.pdf Yeah, I think this approach could actually work really well to aid in reasoning about event ordering. The first example that came to mind was adding an attribute to event handlers that a user wants to be serialized as part of a context: event protocol_event_1(c: connection ...) &context = { return c$id; } { ... } I only skimmed the paper, though seemed like it outlined a similar way of generalizing contexts/scopes ? - Jon _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev