Below is an excerpt from the KQUEUE's Error section for kevent(): [EINTR] A signal was delivered before the timeout expired and before any events were placed on the kqueue for return. [EINTR] A cancellation request was delivered to the thread, but not yet handled. This looks like an error and, if not, it is confusing. If it isn't, could the descriptions be consolidated into one statement?
This double-EINTR was added in r280818 by kib. I cannot say with confidence that the correct thing to do is coalesce the two descriptions into one, due to the claim added later in the manual page that "When kevent() call fails with EINTR error, all changes in the changelist have been applied." Kostik, what do you think?
(In reply to Benjamin Kaduk from comment #1) It is usual practice to list same error code several times when the reasons for errors reported are unrelated. Look at other man pages, my first (almost random) selection of open(2) gave ample source of examples, e.g. for ENOENT, EACCESS, EPERM and others. In other words, there is nothing to fix, since the descriptions of the two listed EINTR reasons are obviously different. More, the text follows the existing practice.
This is deviating from the original bug report and is an engineering question, but shouldn't there be separate error codes when the root cause of an error differs? Otherwise, you start down the path of branched error code analysis. Example: switch( errno ) { case EINTR: { if( /*Check condition one*/ ) { } else if( /*Condition 2*/ ) { } break; } };
(In reply to Michael Cress from comment #3) I believe that the behavior of kevent() is in conformance with POSIX (IEEE Std 1003.1-2001) here, although admittedly it probably doesn't //need// to follow that standard since kqueue()/kevent() is not defined by POSIX. Anyway, returning EINTR seems to make sense from this text: The side effects of acting upon a cancellation request while suspended during a call of a function are the same as the side effects that may be seen in a single-threaded program when a call to a function is interrupted by a signal and the given function returns [EINTR]. Any such side effects occur before any cancellation cleanup handlers are called. I would suggest that this bug be closed, "Works as Intended".
Cancellation is only checked after the syscall return. In other words, the statement that EINTR return implies that all changes are applied, is true.