interruted system call - Unix

This is a discussion on interruted system call - Unix ; In my project I consider only the SIGPIPE signal (ignoring it): .... struct sigaction act; act.sa_handler=SIG_IGN; sigaction(SIGPIPE, &act, NULL); .... I DON'T CONSIDER OTHER SIGNAL. I use system call like accept, connect, read, write,.. the can be interrupted by a ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: interruted system call

  1. interruted system call

    In my project I consider only the SIGPIPE signal (ignoring it):
    ....
    struct sigaction act;
    act.sa_handler=SIG_IGN;
    sigaction(SIGPIPE, &act, NULL);
    ....
    I DON'T CONSIDER OTHER SIGNAL.
    I use system call like accept, connect, read, write,.. the can be
    interrupted by a signal.
    The man page for accept and connect say the return -1 with errno=EINTR
    when "a connection was interrupted by delivery of a
    signal that was CAUGHT".
    Ignoring a signal is as caughting a signal?
    In other word is possible, in my project, connect return -1 with
    errno=EINTR(I just ignore SIGPIPE)?
    If the answer is yes, shall I call connect again (as in a restart
    function) or no (I have read that call connect again on the same
    socket after a connect failure is an error)??


  2. Re: interruted system call

    On 6 Apr., 21:11, "gio" wrote:
    > In my project I consider only the SIGPIPE signal (ignoring it):
    > ...
    > struct sigaction act;
    > act.sa_handler=SIG_IGN;
    > sigaction(SIGPIPE, &act, NULL);
    > ...
    > I DON'T CONSIDER OTHER SIGNAL.
    > I use system call like accept, connect, read, write,.. the can be
    > interrupted by a signal.
    > The man page for accept and connect say the return -1 with errno=EINTR
    > when "a connection was interrupted by delivery of a
    > signal that was CAUGHT".
    > Ignoring a signal is as caughting a signal?
    > In other word is possible, in my project, connect return -1 with
    > errno=EINTR(I just ignore SIGPIPE)?
    > If the answer is yes, shall I call connect again (as in a restart
    > function) or no (I have read that call connect again on the same
    > socket after a connect failure is an error)??


    Ignoring does not mean the same as receiving a signal with an empty
    signal handler.EINTR is not an error, just an indication that a not
    ignored signal has interrupted
    the system call. The system call should be repeated in this case.

    In your case, you do not need to repeat iff SIGPIPE is the only
    exptected signal handler and is ignored. However, according to POSIX
    the behaviour or a process is unspecified after ingoring a SIGPIPE
    signal sent by the system. The default action, terminating the writer
    process, is much better. Consider to let the process go away after
    SIGPIPE, which under nomal circumstances only occurs if the reader
    closes the pipe before the writer and tells the writer that no one
    reads the pipe any more.

    Hubble.


  3. Re: interruted system call

    "Hubble" wrote, on Sat, 07 Apr 2007 22:08:59 -0700:

    > However, according to POSIX
    > the behaviour or a process is unspecified after ingoring a SIGPIPE
    > signal sent by the system.


    No. That statement applies to hardware generated signals such as
    SIGFPE, SIGILL, and SIGSEGV; not to SIGPIPE.

    POSIX requires that if a SIGPIPE signal is ignored, then the write()
    call that triggered it fails with an EPIPE error.

    --
    Geoff Clare


+ Reply to Thread