Date: Mon, 15 Nov 2010 11:37:23 -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: <4CE18BF3.4080301@freebsd.org> In-Reply-To: <20101115183807.GW11110@cel.leo> References: <20101112184000.GS11110@cel.leo> <201011151125.42697.jhb@freebsd.org> <20101115181211.GV11110@cel.leo> <4CE17CF5.6050107@freebsd.org> <20101115183807.GW11110@cel.leo>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/15/10 10:38 AM, Paul LeoNerd Evans wrote: > On Mon, Nov 15, 2010 at 10:33:25AM -0800, Julian Elischer wrote: >> it was provided for pretty much what you are using it for, so that >> the userland caller could >> easily associate the returning event with some private information >> about the event. > This was indeed the impression I got. With reference to my original > questions regarding its use, perhaps you could suggest some way to > actually use this API then, in order to solve my problem? > > Unless there's some subtle detail or trick I have misunderstood, it > doesn't appear to be easily possible in this manner. > > How would you suggest I manage these pointers and data structures? > I don't think it was thought of in the context of reference counted items. 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CE18BF3.4080301>