From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 26 21:45:57 2015 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA5FC540 for ; Thu, 26 Mar 2015 21:45:57 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6C594E6E for ; Thu, 26 Mar 2015 21:45:57 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2QLjpQj094242 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 26 Mar 2015 23:45:51 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2QLjpQj094242 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2QLjpq7094229; Thu, 26 Mar 2015 23:45:51 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 26 Mar 2015 23:45:51 +0200 From: Konstantin Belousov To: Jilles Tjoelker Subject: Re: kevent behavior Message-ID: <20150326214551.GG2379@kib.kiev.ua> References: <550A6DA2.1070004@gmail.com> <20150324221541.GA67584@stack.nl> <20150325090041.GY2379@kib.kiev.ua> <20150325223530.GA79065@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150325223530.GA79065@stack.nl> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@FreeBSD.org, Ivan Radovanovic X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 21:45:58 -0000 On Wed, Mar 25, 2015 at 11:35:30PM +0100, Jilles Tjoelker wrote: > On Wed, Mar 25, 2015 at 11:00:41AM +0200, Konstantin Belousov wrote: > > On Tue, Mar 24, 2015 at 11:15:41PM +0100, Jilles Tjoelker wrote: > > > Fortunately, EVFILT_USER provides an easy way to wake up a thread > > > blocked in kevent(). > > > > If kevent() was implemented as a cancellation point, pthread_cancel() > > > would be another option, but it is not. > > > Do you consider it is possible to make kqueue(2) cancellation point ? > > Susv4 is very explicit about functions it allows to handle cancellation. > > Might be, it is time for kqueue2(3), which would take flags. > > In addition to allowing cancellation, it could take close-on-exec flag. > > > It is somewhat non-trivial to implement, at least I do not want to make > > kevent2(). > > I take it you mean making kevent() a cancellation point, not kqueue(). > The latter would just annoy application writers for no benefit. Um, sorry, yes. > > POSIX does not say anything about kevent(), including whether it should > be a cancellation point or not. Given that kevent() may block for a long > time, making it a cancellation point seems to make sense. But POSIX language is very explicit for its own set of interfaces, and that makes sense. This is why I think that cancellability, after the 15+ years of kqueue existence, should be opt in. > > The kevent() cancellation point implementation would be much like most > other cancellation points such as pselect(), with the difference that > the call may have committed even if it fails, in the case that > nchanges > nevents and in the case that nchanges > 0 && errno == EINTR. > If cancellation is requested while blocking in the latter case, libthr > will have to return -1/EINTR to indicate to the application that the > changes were applied successfully while allowing the thread to be > cancelled at the next cancellation point, even though there may not be > any signal handler. > > If nevents == 0, kevent() does not block and need not be a cancellation > point. This special case may simplify things slightly for application > programmers. > > A kqueue() flag for cancellation does not seem very useful: since such a > flag would be a kernel thing and pthread cancellation is a libthr thing, > requesting the flag from the kernel would slow down all kevent() calls. Yes, I thought about adding some (small) userspace table which would track cancellable kqueues. But if we make the cancellation state per-call, and not a state for kqueue descriptor, we might indicate the cancellability by some event type, which is not passed to the kernel at all. The libthr wrapper for kevent(2) would need to scan the changelist and zero-out the cancellation indicator.