followup: stuck lmtpd processes

[Henrique de Moraes Holschuh]

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).

As for old legacy systems (too old BSDs, SunOS 4, very old Linux), well, I
am inclined to simply ignore them.  Let them use solution (2) above.  That
is the least of their problems, given the amount of annoying and dangerous
bugs those old kernels have.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh