Managing userland data pointers in kqueue/kevent

[Dirk Engling]

On 13.05.13 11:19, Eugen-Andrei Gavriloaie wrote:

> Regardless, it has all the ingredients for memory leaks and/or, the
> worst one, use of corpse pointers which are bound to crash the app. I

I earlier pointed out other things that prevent me from using kqueue as
a proper storage for user land pointers:

http://lists.freebsd.org/pipermail/freebsd-hackers/2013-March/042181.html

To sum it up, once I pass a pointer via udata to the kqueue system,
kqueue becomes the owner and the expected behaviour is

  (a) never silently swallow the pointer
  (b) provide an interface to retrieve the pointer anytime

Besides the way you pointed out to violate (a), there is another way,
re-adding an existing event. So I propose a flag EV_EXCL that will fail
adding an existing event with EEXIST in data.

As an alternative or in addition to that, re-adding an existing event
without the EV_EXCL flag will cause the old event to be returned with
the EV_DROPPED mechanism proposed.

This can also be used to fulfill property (b). kqueue is an efficient
store for the per-event-data. In an event base application, I usually
allocate resources per new session, pass the metadata via udata to
kevent and will see the udata pointer whenever the event triggers.

But in order to clean up resources due to external events (like program
termination), I have no way to ask my kqueue for the kevents (and thus
the udata) I stored in them ... without knowing about them in the first
place.

For the program termination case, it would be enough to extend EV_DELETE
with a flag to drop all filters and catch them by checking for the
EV_DROPPED flag. This means that EV_DELETE could return a list of
filters and can be called several times until no events are returned.

Of course this can be extended to specifically drop events that match a
certain filter, flag or fflag value, but for now you can also use
different kqueues.

Regards,

  erdgeist