Michael T Kerrisk <yyyyyyyyy@xxxxxxx> said:
> While I'm guess that you are taking a devil's advocate position here,
> I assume that we agree that the natural (and probably intended)
> interpretation of the standard is:
>
> 1. EINTR will occur when a system call is interrupted by a
> signal *handler*.
>
> 2. In the absence of a signal handler, the combination of a
> stop-signal+SIGCONT will be invisible to the the receiving
> process (i.e., it will continue execution as though nothing
> happened).
Yes.
Still (putting the devil's advocate hat back on), even if nothing happened,
the call would still be allowed to return EINTR for some reason, perhaps
completely unrelated to signals or signal handlers. An implementation that
returns bogus errors at random is not necessarily non-conforming, as long as
it makes sure to report required errors correctly.
In practice, we don't have to worry about poor-quality implementations like
that, but the theoretical possibility affects programs that want to claim
strict conformance. If your application assumes that an EINTR guarantees
that one of its signal handlers has run, it's not strictly conforming.
|