Date: Thu, 26 Mar 2015 23:58:27 +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: <20150326225826.GA97319@stack.nl> In-Reply-To: <20150326214551.GG2379@kib.kiev.ua> References: <550A6DA2.1070004@gmail.com> <20150324221541.GA67584@stack.nl> <20150325090041.GY2379@kib.kiev.ua> <20150325223530.GA79065@stack.nl> <20150326214551.GG2379@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150326225826.GA97319>