From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 25 22:35:34 2015 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4D33B8E for ; Wed, 25 Mar 2015 22:35:34 +0000 (UTC) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 99084D42 for ; Wed, 25 Mar 2015 22:35:34 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 747313592EF; Wed, 25 Mar 2015 23:35:30 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 4BC1428494; Wed, 25 Mar 2015 23:35:30 +0100 (CET) Date: Wed, 25 Mar 2015 23:35:30 +0100 From: Jilles Tjoelker To: Konstantin Belousov Subject: Re: kevent behavior Message-ID: <20150325223530.GA79065@stack.nl> References: <550A6DA2.1070004@gmail.com> <20150324221541.GA67584@stack.nl> <20150325090041.GY2379@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150325090041.GY2379@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) 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: Wed, 25 Mar 2015 22:35:34 -0000 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. 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. 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. -- Jilles Tjoelker