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