Date: Mon, 15 Nov 2010 18:12:11 +0000 From: Paul LeoNerd Evans <leonerd@leonerd.org.uk> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Managing userland data pointers in kqueue/kevent Message-ID: <20101115181211.GV11110@cel.leo> In-Reply-To: <201011151125.42697.jhb@freebsd.org> References: <20101112184000.GS11110@cel.leo> <201011151125.42697.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Ii7PBTTHr1LoMMv3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Nov 15, 2010 at 11:25:42AM -0500, John Baldwin wrote:
> I think the assumption is that userland actually maintains a reference on=
the=20
> specified object (e.g. a file descriptor) and will know to drop the assoc=
iated=20
> data when the file descriptor is closed. That is, think of the kevent as=
a=20
> member of an eventable object rather than a separate object that has a=20
> reference to the eventable object. When the eventable object's reference=
=20
> count drops to zero in userland, then the kevent should be deleted, eithe=
r via=20
> EV_DELETE, or implicitly (e.g. by closing the associated file descriptor).
Ah. Well, that could be considered a bit more awkward for the use case I
wanted to apply. The idea was that the udata would refer effectively
to a closure, to invoke when the event happens. The idea being you can
just add an event watcher by, say:
$ev->EV_SET( $pid, EVFILT_PROC, 0, NOTE_EXIT, 0, sub {
print STDERR "The child process $pid has now exited\n";
} );
So, the kernel's udata pointer effectively holds the only reference to
this anonymous closure. It's much more flexible this way, especially for
oneshot events like that.
The beauty is also that the kevents() loop can simply know that the
udata is always a code reference so just has to invoke it to do whatever
the original caller wanted to do.
Keep in mind my use-case here; I'm not trying to be one specific
application, it's a general-purpose kevent-wrapping library.
> I think in your case you should not give the kevent a reference to your=
=20
> object, but instead remove the associated event for a given object when a=
n=20
> object's refcount drops to zero.
Well that's certainly doable in longrunning watches, but I don't think
it sounds very convenient for a oneshot event; see the above example for
justification.
Also it again begs my question, worth repeating here:
On Friday, November 12, 2010 1:40:00 pm Paul LeoNerd Evans wrote:
> I had
> thought the point of kqueue/kevent is the O(1) nature of it, which is
> among why the kernel is storing that void *udata pointer in the first
> place. If I have to store a mapping from every filter+identity back to
> my data pointer, why does the kernel store one at all? I could just
> ignore the udata field and use my mapping for my own purposes.
If you're saying that in my not-so-rare use case, I don't want to be
using udata, and instead keeping my own mapping, why does the kernel
provide this udata field at all?
--=20
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
--Ii7PBTTHr1LoMMv3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iD8DBQFM4Xf7vLS2TC8cBo0RAiWdAJ4xbkjLKNitZgV8rT+4353OFQk08gCg44pu
Upnxi26cqde1GFthTj4KiGo=
=KwOH
-----END PGP SIGNATURE-----
--Ii7PBTTHr1LoMMv3--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101115181211.GV11110>