[Bro-Dev] 'async' update and proposal

[Robin Sommer]

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 * robin at icir.org * www.icir.org/robin