On Wed, 15 May 2013 13:29:59 +0100 Paul "LeoNerd" Evans <leon...@leonerd.org.uk> wrote:
> Is that not the exact thing I suggested?
>
> The "extension to create register a kevent to catch these events" is
> that you put the EV_DROPWATCH bit flag in the event at the time you
> register it.
>
> The "returned event [that] could have all the appropriate informaiton
> for the event being dropped" is that you receive an event with
> EV_DROPPED set on it. It being a real event includes of course the
> udata pointer, so you can handle it.
In fact, to requote the original PR I wrote[1] on the subject:
---
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
close(2).
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.
---
[1]: http://www.freebsd.org/cgi/query-pr.cgi?pr=153254
--
Paul "LeoNerd" Evans
leon...@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: PGP signature
