From owner-freebsd-hackers@FreeBSD.ORG Sat May 18 18:32:13 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 831763AF for ; Sat, 18 May 2013 18:32:13 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: from elektropost.org (elektropost.org [217.13.206.130]) by mx1.freebsd.org (Postfix) with ESMTP id EC819DBC for ; Sat, 18 May 2013 18:32:11 +0000 (UTC) Received: (qmail 7884 invoked from network); 18 May 2013 18:32:08 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with CAMELLIA256-SHA encrypted SMTP; 18 May 2013 18:32:08 -0000 Message-ID: <5197C925.8060205@erdgeist.org> Date: Sat, 18 May 2013 14:32:05 -0400 From: Dirk Engling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Eugen-Andrei Gavriloaie Subject: Re: Managing userland data pointers in kqueue/kevent References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 18:32:13 -0000 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