[Bro-Dev] [Proposal] Language extensions for better Broker support

Matthias Vallentin vallentin at icir.org
Tue Dec 13 09:42:10 PST 2016

> >  local r = put(store, key, test(lookup(store, key)));
> For prototyping purposes, I see the convenience in that, but wonder if
> the runtime will do something that’s useful and widely applicable
> enough for that to translate directly into production code.  What
> exactly does the runtime do if “lookup” fails here besides turn the
> outer function calls into no-ops?

The runtime doesn't do anything but error propagation. That's a plus in
my opinion, because it's simple to understand and efficient to

> Just guessing, but in many cases one would additionally want to log a
> warning and others where they even want to schedule the operation to
> retry at a later time.  i.e. the treatment of the failure varies with
> the context.  Is this type of composition flexible enough for that?

It's up to the user to check the result variable (here: r) and decide
what to do: abort, retry, continue, or report an error. Based on what
constitutes a self-contained unit in an algorithm, there are natural
points where one would try again. In the above example, perhaps at the
granularity of that put-test-lookup chain. To try again after a timeout,
I would imagine it as follows:

    local algorithm = function() : result {
      return put(store, key, test(lookup(store, key))) &timeout = 3 sec;

    local r = result();
    do {
      r = algorithm(); 
    } while (r?$error && r$error == timeout);

Based on how flexible we design the type in r$error, it can represent
all sorts of errors. The runtime could abort for critical errors, but
give control back to the user when it's a recoverable one.


More information about the bro-dev mailing list