I just wanted to quickly chime in here to say that I generally like the
idea of having these contexts. I have no idea how complex it would be to
implement something like this, but that seems like it might be a
relatively clean solution to our problem :)
Johanna
On Tue, Jan 30, 2018 at 07:38:42AM -0800, Robin Sommer wrote:
>
>
> 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
>
_______________________________________________
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
