[Bro-Dev] 'async' update and proposal

[Azoff, Justin S]

> 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(...)
> 	{
> 	Log::write([....c$proto$la...]);
> 	}

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

        add n$email_delay_tokens["hostnames-src"];
        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;
            delete tmp_notice_storage[uid]$email_delay_tokens["hostnames-src"];
            }

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;
	}

event protocol_event_1(...)
	{
	...
	}

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.


— 
Justin Azoff