Erik Faye-Lund <kusmab...@gmail.com> writes: > On Wed, Jan 23, 2013 at 4:32 PM, Thomas Rast <tr...@student.ethz.ch> wrote: >> Erik Faye-Lund <kusmab...@gmail.com> writes: >> >>> POSIX allows error codes >>> to be generated other than those defined. From >>> http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_03.html: >>> >>> "Implementations may support additional errors not included in this >>> list, *may generate errors included in this list under circumstances >>> other than those described here*, or may contain extensions or >>> limitations that prevent some errors from occurring." >> >> That same page says, however: >> >> For functions under the Threads option for which [EINTR] is not listed >> as a possible error condition in this volume of IEEE Std 1003.1-2001, >> an implementation shall not return an error code of [EINTR]. > > Yes, but surely that's for pthreads functions, no? utime is not one of > those functions...
Ah, my bad. In fact in http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap02.html there is a paragraph "Signal Effects on Other Functions", which says The most common behavior of an interrupted function after a signal-catching function returns is for the interrupted function to give an [EINTR] error unless the SA_RESTART flag is in effect for the signal. However, there are a number of specific exceptions, including sleep() and certain situations with read() and write(). The historical implementations of many functions defined by IEEE Std 1003.1-2001 are not interruptible[...] Functions not mentioned explicitly as interruptible may be so on some implementations, possibly as an extension where the function gives an [EINTR] error. There are several functions (for example, getpid(), getuid()) that are specified as never returning an error, which can thus never be extended in this way. If a signal-catching function returns while the SA_RESTART flag is in effect, an interrupted function is restarted at the point it was interrupted. Conforming applications cannot make assumptions about the internal behavior of interrupted functions, even if the functions are async-signal-safe. For example, suppose the read() function is interrupted with SA_RESTART in effect, the signal-catching function closes the file descriptor being read from and returns, and the read() function is then restarted; in this case the application cannot assume that the read() function will give an [EBADF] error, since read() might have checked the file descriptor for validity before being interrupted. Taken together this should mean that the bug is in fact simply that the calls do not *restart*. They are (like you say) allowed to return EINTR despite not being specified to, *but* SA_RESTART should restart it. Now, does that make it a lustre bug or a glibc bug? :-) -- Thomas Rast trast@{inf,student}.ethz.ch -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
