Re: [Bro-Dev] 'async' update and proposal

>I think we should instead just skip the "async" keyword altogether. >Requiring it at some places, but not others, hurts more than it helps >in my opinion. This sounds fine to me. Given that Bro is inherently an asynchronous language, it makes sense to for those semantics to trickle down to the

Re: [Bro-Dev] 'async' update and proposal

Ok, agree that it's best to postpone "async". My gut isn't quite as skeptical about its safety but I see the argument. (Although then nobody will be allowed to complain about "when" anymore ;-) Jon, if you want to think more about context/scoping it would be great to keep the concurrency aspects

Re: [Bro-Dev] 'async' update and proposal

On 13 Feb 2018, at 7:44, Robin Sommer wrote: > On Thu, Feb 08, 2018 at 10:01 -0800, Johanna wrote: > >> I just wanted to quickly chime in here to say that I generally like >> the >> idea of having these contexts. > > Sounds like we all like that idea. Now the question is if we want to > wait

Re: [Bro-Dev] 'async' update and proposal

On Tue, Feb 13, 2018 at 9:44 AM, Robin Sommer wrote: > Sounds like we all like that idea. Now the question is if we want to > wait for that to materialize (which will take quite a bit more > brainstorming and then implementation, obviously), or if we want to > get async in in the

Re: [Bro-Dev] 'async' update and proposal

On Thu, Feb 08, 2018 at 10:01 -0800, Johanna wrote: > I just wanted to quickly chime in here to say that I generally like the > idea of having these contexts. Sounds like we all like that idea. Now the question is if we want to wait for that to materialize (which will take quite a bit more

Re: [Bro-Dev] 'async' update and proposal

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

Re: [Bro-Dev] 'async' update and proposal

On Tue, Jan 30, 2018 at 10:28 -0600, you wrote: > Was there more benefit of using the predefined choice than saving the > overhead of calling out to script-land to do the context calculation? No, don't think so. It mainly came out of an analysis of existing scripts, and those 5-tuple based

Re: [Bro-Dev] 'async' update and proposal

On Tue, Jan 30, 2018 at 9:38 AM, Robin Sommer wrote: > 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

Re: [Bro-Dev] 'async' update and proposal

On Tue, Jan 30, 2018 at 10:11 -0500, you wrote: > I like this idea a lot! Yeah, I like it, too. Additional benefit: it actually opens the door for parallelization again, too ... > Do you foresee that causing trouble if we went that direction > though? It seems like it could cause

Re: [Bro-Dev] 'async' update and proposal

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.

Re: [Bro-Dev] 'async' update and proposal

On 29 Jan 2018, at 12:00, Robin Sommer wrote: > Actually, I think one > possible solution has been floating around for a while already: event > *scopes* that express serialization requirements in terms of shared > context. I like this idea a lot! Do you foresee that causing trouble if we went

Re: [Bro-Dev] 'async' update and proposal

On Mon, Jan 29, 2018 at 11:00 AM, Robin Sommer wrote: > as you point out, that wouldn't solve inter-event dependencies. > Per Jan's mail, one can work around that with custom code The inter-event dependencies + code understandability/readability issue that Johanna points out is

Re: [Bro-Dev] 'async' update and proposal

Jan wrote: > First of all, this async keyword reminds me of asynchronous programming > in C#: Nice, didn't know 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

Re: [Bro-Dev] 'async' update and proposal

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

Re: [Bro-Dev] 'async' update and proposal

> On Jan 27, 2018, at 12:25 AM, Johanna Amann 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...]); >

Re: [Bro-Dev] 'async' update and proposal

> I don't think skipping "async" this would be a big deal for anything, > as the cases where the new behaviour may actually lead to significant > differences should be rare. After pondering this for a while I am a bit afraid that skipping async completely might lead to quite hard to debug