Managing userland data pointers in kqueue/kevent

Paul LeoNerd Evans leonerd at leonerd.org.uk
Wed May 15 12:35:01 UTC 2013


On Wed, 15 May 2013 13:29:59 +0100
Paul "LeoNerd" Evans <leonerd at 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

leonerd at leonerd.org.uk
ICQ# 4135350       |  Registered Linux# 179460
http://www.leonerd.org.uk/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20130515/e1c6a9b9/attachment.sig>


More information about the freebsd-hackers mailing list