On Wed, Sep 24, 2003 at 02:20:50PM -0300, Henrique de Moraes Holschuh wrote: > On Wed, 24 Sep 2003, Etienne Goyer wrote: > > On Wed, Sep 24, 2003 at 11:27:46AM -0400, Rob Siemborski wrote: > > > However, I have looked into this and to my surprise, Linux is indeed > > > restarting the system calls instead of returning with EINTR. However, the > > > answer here is to set up the alarm() handler with sigaction without > > > setting SA_RESTART, not to jump through select() hoops or make nonblocking > > > lock attempts. > > > > I consult my local Unix guru on the subject, and he point me to > > "Advanced Programming in the Unix Environment" by W. Richard Stevens, > > section 10.5 (page 275 in my edition) "Interrupted System Calls". > > The revelancy of this text may be questionned since it was published in > > 1992, but the behavior of SVR4 vs BSD differ substantially in this > > regard according to it. My guru concluded that system call interuption > > by signal is an assumption that may lead to portability problem. In the > > fud case, he is right. > > With SYSV you will get the interrupted system call, unless you tell it > somehow not to do it (the SA_RESTART stuff). If we are to accomodate the > BSDs, we can: > 1. Let them have the short end of the stick (they get what we have now, > that is, deadlocks). Not good. > 2. Let them use the low-performance non-blocking mode (good solution). > 3. Find out how to get EINTR from BSD (it should be possible nowadays).
I don't understand. The only alarm() business I can see in imap/fud.c is around recvfrom which at least according to its man page says [EINTR] The receive was interrupted by delivery of a signal before any data were available. What "system call"s are there? I was looking for syscall()... Cheers, Patrick