[Zeek-Dev] support for event handlers using a subset of parameters

Jon Siwek jsiwek at corelight.com
Fri Feb 1 11:47:12 PST 2019


On Fri, Feb 1, 2019 at 12:59 PM Vern Paxson <vern at corelight.com> wrote:

> I don't see how it helps with
> deprecating existing parameters (which seems would be better served with
> some sort of &deprecated attribute),

Support for &deprecated in parameters is part of the changes.

But if we don't allow the user to immediately remove the field, they
are then stuck doing 2 changes:

Step 1: we mark a field &deprecated
Step 2: the user sees that, so they remove uses of that parameter from
their body
Step 3: we actually remove the &deprecated field
Step 4: if the user was forced to still have the &deprecated param in
their handler's param list they now have to do a second change to
remove it instead of just removing it right away

With the proposed patch, we get rid of the need for Step 4 and
decrease burden on users.

> and I don't see how it helps with
> changing the semantics of existing event parameters.

Step 1: we mark old field &deprecated and introduce a new parameter
Step 2: the users sees that.. etc, etc. same as above.

> It actually makes sense to me to support overloading for events.  Then for
> example you could have two event signatures depending on what information
> the handler was going to leverage, which would allow the event engine to
> offload work if there isn't a handler for a signature that requires extra
> computation.

I think the same kind of offloading is possible with the "parameter
subset" approach.   We know exactly what parameters are being
consumed, so we might have optimizations that don't produce a
parameter if no one consumes it.  And if no one consumes any
parameters we also don't generate the call.

If you have two different event signatures, we just get the same type
of optimization we currently do, which only optimize out the entire
call if there's no handlers, but doesn't know if individual parameters
are being consumed or not.  e.g:

    http_request(a, b, c)
    http_request(d, e, f)

If someone only consumes 'a' and 'e', you still have to produce both
function calls in their entirety (and also the other unused params),
but:

    http_request(a, b, c, d, e, f)

You can potentially not do any work generating the unused parameters
and only have to do the one function call with 'a' and 'e'.

Technically, we can still require a matching signature and do such an
optimization by walking the AST and finding local parameter usages.  I
guess you have to do that ultimately, but it's an easy head start at
implementing such optimizations as a test/idea if we can simply see
someone isn't using a parameter because it's not in their handler
param list.

- Jon


More information about the zeek-dev mailing list