From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 26 22:58:30 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 47B92F50 for ; Thu, 26 Mar 2015 22:58:30 +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 0827F869 for ; Thu, 26 Mar 2015 22:58:30 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 3E84A358C5A; Thu, 26 Mar 2015 23:58:27 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 22E7228494; Thu, 26 Mar 2015 23:58:27 +0100 (CET) Date: Thu, 26 Mar 2015 23:58:27 +0100 From: Jilles Tjoelker To: Konstantin Belousov Subject: Re: kevent behavior Message-ID: <20150326225826.GA97319@stack.nl> References: <550A6DA2.1070004@gmail.com> <20150324221541.GA67584@stack.nl> <20150325090041.GY2379@kib.kiev.ua> <20150325223530.GA79065@stack.nl> <20150326214551.GG2379@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150326214551.GG2379@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: Thu, 26 Mar 2015 22:58:30 -0000 On Thu, Mar 26, 2015 at 11:45:51PM +0200, Konstantin Belousov wrote: > On Wed, Mar 25, 2015 at 11:35:30PM +0100, Jilles Tjoelker wrote: > > 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. Hmm, I think most code written is cancel-unsafe. It is unlikely to have cancel-safe code using kevent() and relying on it not being a cancellation point, but still possible. This also means we shouldn't wait too long with adding missing cancellation points like ppoll(). > > 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. I think the interaction with dup() and similar calls and with exec makes this too nasty. > 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. This seems a bit hackish. However, enabling cancellation per-call seems better than per-kqueue. -- Jilles Tjoelker