Very Computer

Telecom Australia              
Customised Software
Solutions Centre

Phone:  +61 42 211111           Snail:  Telecom CSSC
Fax:    +61 42 291021                   C/- Illawarra Technology Centre
                                        PO Box 2112
                                        Wollongong 2500

   I am doing some work with internet domain sockets. Occaisonally I
   get an "interrupted system call" error (EINTR). What am I supposed
   to do about this?  Just try again?

In most cases, yes.

However, it's difficult to answer for sure without knowing more about
your program.... What's CAUSING the EINTR?  What signals are you
using?  What system calls are being interrupted?

There are problems with just restarting in some cases.  For example, I
believe it's possible for a write() to be interrupted after part of
the data you give it has already been written, and I don't think
there's any way to know how much data was written before the interrupt
(ugh!).

--

MIT Information Systems/Athena              Moderator, news.answers
    (Send correspondence related to the news.answers newsgroup
        {and ONLY correspondence related to the newsgroup}

Quote:> There are problems with just restarting in some cases.  For example, I
> believe it's possible for a write() to be interrupted after part of
> the data you give it has already been written, and I don't think
> there's any way to know how much data was written before the interrupt
> (ugh!).

---Dan

   On broken systems, and in stupid cases, yes. On working systems write()
   will always return the number of bytes written, if that number is
   positive. (Yes, this is part of my definition of ``working''; yes, there
   exist systems which work in this respect.)

Code that is attempting to be portable does not rely on functionality
that is known not to exist on some machines (in this case, a large
number of machines).

If you want to write code that will functional properly only on
systems that you consider "workins" ones, then by all means, don't
deal with the possibility of partial, interrupted write()s.

If, on the other hand, you want your code to be as portable as
possible and therefore used by as many people as possible, it should
be able to deal with the possibility of brain-damage in the
environment.  At they very least, put in an undocumented set of
#ifdef's to deal with the possibility, so that when people complain
that something's breaking, you can tell them, "Put this -D in the
Makefile and send a flame to your vendor."

--

MIT Information Systems/Athena              Moderator, news.answers
    (Send correspondence related to the news.answers newsgroup
        {and ONLY correspondence related to the newsgroup}

        Upon successful completion the number of bytes actually written is
        returned.  Otherwise, -1 is returned, and errno is set to indicate
        the error.

This follows the usual Unix convention  that  errno  is  only  set  on
failure,  and remains unchanged on success.  It appears that there are
only two outcomes supported by the manual:

        value >= 0 and errno unchanged.
        value = -1 and errno changed.

There is no room here for a non-negative  byte  count  being  returned
when errno is set to EINTR.  It sure would be useful. But if the value
is positive, how is the program to know that the value of errno is  to
be tested?  TFM doesn't seem to admit this as a possibility, much less
say how you might detect that it has happened.

Some people seem to believe that write() *must* return -1/EINTR if the
I/O was interrupted---I've even seen code which assumes this instead of
handling signals properly. But that's the wrong way around. If write()
returns -1 then, on a working system, you can be sure that no bytes were
written successfully; if errno shows up as EINTR you can then conclude
that write() failed because of a signal rather than an I/O error. The
converse statement is false. There are cases, on working systems, when
write() will be interrupted by a signal but will return a positive
number. That's how it should be, if some bytes were written before the
signal. Again: a working system simply does not throw I/O away!

---Dan

Quote:>This follows the usual Unix convention  that  errno  is  only  set  on
>failure,  and remains unchanged on success.