Date: Mon, 15 Nov 2010 12:51:57 -0800 From: Julian Elischer <julian@freebsd.org> To: Paul LeoNerd Evans <leonerd@leonerd.org.uk> Cc: freebsd-hackers@freebsd.org Subject: Re: Managing userland data pointers in kqueue/kevent Message-ID: <4CE19D6D.7000201@freebsd.org> In-Reply-To: <20101115201445.GY11110@cel.leo> References: <20101112184000.GS11110@cel.leo> <201011151125.42697.jhb@freebsd.org> <20101115181211.GV11110@cel.leo> <4CE17CF5.6050107@freebsd.org> <20101115183807.GW11110@cel.leo> <4CE18BF3.4080301@freebsd.org> <20101115201445.GY11110@cel.leo>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/15/10 12:14 PM, Paul LeoNerd Evans wrote: > 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 "keep more information associated with each kevent and use the user cookie to match them" this is what it was for. it's a tool, not an answer. Given this tool you should be able to get what you want. how you do it is your job. It's not the kernel's job to keep application specific data for you.. but it gives you a way to do it yourself and keep track of it trivially. It's expected that for every event the user gives to the kernel, he has some matching information about that event in userland. > me... >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CE19D6D.7000201>