Date: Mon, 15 Nov 2010 20:14:46 +0000 From: Paul LeoNerd Evans <leonerd@leonerd.org.uk> To: Julian Elischer <julian@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Managing userland data pointers in kqueue/kevent Message-ID: <20101115201445.GY11110@cel.leo> In-Reply-To: <4CE18BF3.4080301@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--y0gFD7xD8qWl5Ra4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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... --=20 Paul "LeoNerd" Evans leonerd@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ --y0gFD7xD8qWl5Ra4 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) iD8DBQFM4ZS1vLS2TC8cBo0RAjNsAKC4z14t0dAjdGv+soid67Z0A036iwCbB9bJ sBzFKjy4sf/nZ5uGmnQnPqU= =dwSI -----END PGP SIGNATURE----- --y0gFD7xD8qWl5Ra4--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101115201445.GY11110>