Date: Sat, 18 May 2013 14:32:05 -0400 From: Dirk Engling <erdgeist@erdgeist.org> To: Eugen-Andrei Gavriloaie <shiretu@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Managing userland data pointers in kqueue/kevent Message-ID: <5197C925.8060205@erdgeist.org> In-Reply-To: <CCE4FFC4-F846-4F81-85EE-776B753C63C6@gmail.com> References: <CCE4FFC4-F846-4F81-85EE-776B753C63C6@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13.05.13 11:19, Eugen-Andrei Gavriloaie wrote: > Regardless, it has all the ingredients for memory leaks and/or, the > worst one, use of corpse pointers which are bound to crash the app. I I earlier pointed out other things that prevent me from using kqueue as a proper storage for user land pointers: http://lists.freebsd.org/pipermail/freebsd-hackers/2013-March/042181.html To sum it up, once I pass a pointer via udata to the kqueue system, kqueue becomes the owner and the expected behaviour is (a) never silently swallow the pointer (b) provide an interface to retrieve the pointer anytime Besides the way you pointed out to violate (a), there is another way, re-adding an existing event. So I propose a flag EV_EXCL that will fail adding an existing event with EEXIST in data. As an alternative or in addition to that, re-adding an existing event without the EV_EXCL flag will cause the old event to be returned with the EV_DROPPED mechanism proposed. This can also be used to fulfill property (b). kqueue is an efficient store for the per-event-data. In an event base application, I usually allocate resources per new session, pass the metadata via udata to kevent and will see the udata pointer whenever the event triggers. But in order to clean up resources due to external events (like program termination), I have no way to ask my kqueue for the kevents (and thus the udata) I stored in them ... without knowing about them in the first place. For the program termination case, it would be enough to extend EV_DELETE with a flag to drop all filters and catch them by checking for the EV_DROPPED flag. This means that EV_DELETE could return a list of filters and can be called several times until no events are returned. Of course this can be extended to specifically drop events that match a certain filter, flag or fflag value, but for now you can also use different kqueues. Regards, erdgeist
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5197C925.8060205>