Date: Thu, 26 Mar 2015 23:45:51 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Jilles Tjoelker <jilles@stack.nl> Cc: freebsd-hackers@FreeBSD.org, Ivan Radovanovic <radovanovic@gmail.com> Subject: Re: kevent behavior Message-ID: <20150326214551.GG2379@kib.kiev.ua> In-Reply-To: <20150325223530.GA79065@stack.nl> References: <550A6DA2.1070004@gmail.com> <20150324221541.GA67584@stack.nl> <20150325090041.GY2379@kib.kiev.ua> <20150325223530.GA79065@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150326214551.GG2379>