kevent behavior

[Jilles Tjoelker]

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