On Mon, Jan 29, 2018 at 13:58 -0600, you wrote:
> 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. That's a good point more generally: if we require "async" at call sites, an internal change to a framework can break existing code. > 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 ? Yeah, that's pretty much the idea there. For concurrency, we'd hash that context value and use that to determine a target threat to schedule execution too, just like in a cluster the process/machine is determined. An attribute can work if we're confident that the relevant information can always be extracted from the event parameters. In a concurrent prototype many years ago we instead used a hardcoded set of choices based on the underlying connection triggering the event (5-tuple, host pair, src IP, dst IP). So you'd write (iirc): event protocol_event_1(c: connection ...) &scope = connection That detaches the context calculation from event parameters, with the obvious disadvantage that it can't be customized any further. May be there's some middle ground where we'd get both. (To clarify terminology: In that paper "scope" is the scheduling granularity, e.g., "by connection". "context" is the current instantiation of that scope (e.g., "1.2.3.4:1234,2.3.4.5:80" for connection scope). Robin -- Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev