followup: stuck lmtpd processes

[Patrick Welche]

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