[Bro-Dev] 'async' update and proposal
Azoff, Justin S
jazoff at illinois.edu
Sun Jan 28 07:13:11 PST 2018
> On Jan 27, 2018, at 12:25 AM, Johanna Amann <johanna at icir.org> wrote:
> Consider e.g. an example like the following
> event protocol_event_1(...)
> c$proto$la = function_call;
> event protocol_event_end(...)
I was thinking the same thing :-)
The notice framework currently has this problem, and needs to work around it:
## Adding a string "token" to this set will cause the notice
## framework's built-in emailing functionality to delay sending
## the email until either the token has been removed or the
## email has been delayed for :bro:id:`Notice::max_email_delay`.
email_delay_tokens: set[string] &optional;
So that the extend-email hostnames script can do
when ( local src_name = lookup_addr(n$src) )
output = string_cat("orig/src hostname: ", src_name, "\n");
tmp_notice_storage[uid]$email_body_sections[|tmp_notice_storage[uid]$email_body_sections|] = output;
So 'async' or no 'async' keyword, I think as soon as bro starts doing more things asynchronous a lot of synchronization/ordering issues come into play.
Even stuff like
event protocol_event_1(...) &priority=1
c$proto$la = function_call;
Currently the 2nd event handler is guaranteed to be ran only after the first finishes running, right? But what if the first handler does an async operation?
Does the 2nd event handler wait for the async operation to finish, or does it run as soon as the higher priority event function hits an async operation?
If that works, it would be because there's an explicit dependency on the higher priority event with the lower priority event.
For 'protocol_event_1' and 'protocol_event_end' there's no explicit dependency other than that the analyzer raises the events with a known ordering.
If an earlier event can trigger an async operation then all of the assumed ordering goes out the window.
More information about the bro-dev