[Bro-Dev] 'async' update and proposal

Jan Grashöfer jan.grashoefer at gmail.com
Sun Jan 28 12:45:11 PST 2018


First of all, this async keyword reminds me of asynchronous programming
in C#:
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/async/

As I only used it in a student project, I don't have real experience but
maybe someone who is used to that paradigm in C# can provide some
valuable hints.

>> So - my argument is basically exactly the reverse of yours - if an async
>> function is somewhere in the call stack I definitely would want to know
>> about this when writing my script - otherwhise I can see really nasty bugs
>> happening.

I agree on that! For the C# async paradigm, people say that async is
like a zombie plague as a single asynchronous function can start
"infecting" your code base by propagating async through the call graph.
However, I would prefer being explicit, in particular as in case of Bro
the plague syntactically stops at the event level.

> 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(...)
> 	{
> 	...
> 	}
> 
> [...]
> 
> 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.

That's a really good example I think. However, with async around, I
would argue that the priority can be used to determine when an event is
scheduled but not when it is finished. In cases where ordering is
important, wouldn't something like the following work?

event protocol_event_1(...)
	{
	c$steps_left = 2;
	c$proto$la = async function_call;
	c$steps_left--;
	if ( c$steps_left <= 0 )
		schedule 0sec { protocol_event_end(...) };
	}

event protocol_event_2(...)
	{
	# do stuff
	c$steps_left--;
	if ( c$steps_left <= 0 )
		schedule 0sec { protocol_event_end(...) };
	}

event protocol_event_end(...)
	{
	# Log write or whatever
	}

As it is explicit as well, this pattern could significantly blow up
scripts. Anyway, I think asynchronous control flow is just more complex
than sequential, no matter how much syntactic sugar is put on top.

Jan


More information about the bro-dev mailing list