misc/153254: Please add API to kqueue(2) to notify when watches are
leonerd-freebsd at leonerd.org.uk
Fri Dec 17 17:00:26 UTC 2010
>Synopsis: Please add API to kqueue(2) to notify when watches are dropped
>Arrival-Date: Fri Dec 17 17:00:19 UTC 2010
>Originator: Paul Evans
kevent(2) can be used to pass userland pointers into the kernel's watch structure, via the void *udata field. Kernel holds these pointers in the knote structure in the kernel, until such time as they are dropped by the kernel. It does not inform userland of this fact.
This makes it impossible to generically handle memory-management issues (malloc/free or equivalent) in a portable wrapper library.
See my message thread on freebsd-hackers@,
and in particular the issues numbered 1 to 4 in the last message:
I propose the addition of a new flag applicable to any kevent watch structure, documented thusly:
The flags field can contain the following values:
EV_DROPWATCH Requests that the kernel will send an EV_DROPPED event
on this watch when it has finished watching it for any
reason, including EV_DELETE, expiry because of
EV_ONESHOT, or because the filehandle was closed by
EV_DROPPED This flag is returned by the kernel if it is now about
to drop the watch. After this flag has been received,
no further events will occur on this watch.
This flag then makes it trivial to build a generic wrapper for kqueue that can always manage its memory correctly.
a) at EV_ADD time, simply set flags |= EV_DROPWATCH
b) after an event has been processed that included the EV_DROPPED flag,
free() the pointer given in the udata field.
It is not required that these two flags have distinct values; since one is userland->kernel and the other kernel->userland, they could for neatness reuse the same bit field.
Having had a read of the kevent implementation at
I believe it ought to be possible to implement this with only a small change, around 50 lines, mostly altering the behaviour of knote_drop().
I am happy to look into implementing this feature, if you agree it looks useful to add and would be willing to consider accepting it.
More information about the freebsd-bugs