Managing userland data pointers in kqueue/kevent

[Paul LeoNerd Evans]

On Mon, Nov 15, 2010 at 11:37:23AM -0800, Julian Elischer wrote:
> I don't think it was thought of in the context of reference counted items.

This problem has nothing to do with reference counting, and all to do
with resource ownership.

Consider in the totally C-based world, no refcounts, just malloc() and
free(). You malloc() some event structure, put it in the udata field to
the kernel, then return to the main run loop. You've dropped every
reference to this malloc()ed memory, because hey, kernel has it. Later,
event fires, kernel gives you back that pointer. Great. Lets use it. Was
it a PROC|EXIT event? Lets free() the data.

Was it an event that had been registered as EV_ONESHOT? Oops. We can't
remember because kernel didn't tell us.

Want to EV_DELETE it now? Can't, lost the pointer, can't ask kernel for
it back.

Want to close() the filehandle associated? Can't, because kernel has
pointer that it'll drop.

In all these cases we'll memory leak the malloc()ed data.

The only solution here is to keep another copy somewhere up in userland.
This copy has to be associated with the original filter specification,
so that on EV_DELETE we know the pointer so can free() it. But, as I
said, if we're going to keep that mapping, why does the kernel even give
us this udata ability in the first place? We might as well not bother
and use the mapping all the time.

Maybe this just is what people do? That was the thrust of my first
question - _is_ this what people do? I'm not experienced enough with
kqueue to know what is best practice here, and the documentation gives
no guidance. Can someone advise me?

---

Totally separate to that, if nobody has really thought of a solution to
this before, what are anyone's thoughts on my suggestion of the
EV_FREEWATCH flag? Get the kernel always to tell userland that it has
dropped a watch, and return the pointer back, so userland can do
whatever it wants by way of resource reclaimation.



> you could use an ever increasing number that you hash on a hash table.
> if the kernel returns a number that is out of date you won't find it
> and you
> can ignore it. If the kernel returns a number you are currently tracking.
> then you use the item associated with that entry.

I'm really not sure I understand where this is going, or how it helps
me...

-- 
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: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20101115/e52b4547/attachment.pgp