[Bro-Dev] 'async' update and proposal

Jon Siwek jsiwek at corelight.com
Mon Jan 29 11:58:35 PST 2018


On Mon, Jan 29, 2018 at 11:00 AM, Robin Sommer <robin at 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


More information about the bro-dev mailing list