Will SA_RESTART affect behavior of select(2) ? - Unix

This is a discussion on Will SA_RESTART affect behavior of select(2) ? - Unix ; Hi, If I installed a singal handler with SA_RESTART flag enabled, will a following select(2) possiblly return with EINTR? Thanks....

+ Reply to Thread
Results 1 to 10 of 10

Thread: Will SA_RESTART affect behavior of select(2) ?

  1. Will SA_RESTART affect behavior of select(2) ?

    Hi,

    If I installed a singal handler with SA_RESTART flag enabled, will a
    following select(2) possiblly return with EINTR?

    Thanks.

  2. Re: Will SA_RESTART affect behavior of select(2) ?

    Steven Woody wrote:

    > If I installed a singal handler with SA_RESTART flag enabled, will a
    > following select(2) possiblly return with EINTR?


    It won't return with EINTR if your OS is POSIX-compliant.

  3. Re: Will SA_RESTART affect behavior of select(2) ?

    Terry writes:
    > Steven Woody wrote:
    >
    >> If I installed a singal handler with SA_RESTART flag enabled, will a
    >> following select(2) possiblly return with EINTR?

    >
    > It won't return with EINTR if your OS is POSIX-compliant.


    'Officially' this is implementation defined. It is not uncommon for
    both select and poll to always return with an 'was interrupted' error
    code, because restarting the call with the original timeout after some
    time has already passed is not really sensible.

  4. Re: Will SA_RESTART affect behavior of select(2) ?

    Rainer Weikusat wrote:

    > because restarting the call with the original timeout after some
    > time has already passed is not really sensible.


    Yes, but, won't select like system call handle the timeout issue
    automatically upon restarting from interruption ?

  5. Re: Will SA_RESTART affect behavior of select(2) ?

    Terry writes:
    > Rainer Weikusat wrote:
    >
    >> because restarting the call with the original timeout after some
    >> time has already passed is not really sensible.

    >
    > Yes, but, won't select like system call handle the timeout issue
    > automatically upon restarting from interruption ?


    Why do you think I wrote that it won't?

  6. Re: Will SA_RESTART affect behavior of select(2) ?

    On May 26, 4:41 pm, Rainer Weikusat wrote:
    > Terry writes:
    > > Steven Woody wrote:

    >
    > >> If I installed a singal handler with SA_RESTART flag enabled, will a
    > >> following select(2) possiblly return with EINTR?

    >
    > > It won't return with EINTR if your OS is POSIX-compliant.

    >
    > 'Officially' this is implementation defined. It is not uncommon for
    > both select and poll to always return with an 'was interrupted' error
    > code, because restarting the call with the original timeout after some
    > time has already passed is not really sensible.


    The OS is Linux 2.6.xx, so what is the answer? Thank you. Usually, I
    prefer to install a signal handler with SA_RESTART always enabled
    ( excpet for SIGALARM hander ), since I's tedious to process EINTR
    returns for every read/write operation. Do you think so?

  7. Re: Will SA_RESTART affect behavior of select(2) ?

    Steven Woody writes:
    > On May 26, 4:41 pm, Rainer Weikusat wrote:
    >> Terry writes:
    >> > Steven Woody wrote:

    >>
    >> >> If I installed a singal handler with SA_RESTART flag enabled, will a
    >> >> following select(2) possiblly return with EINTR?

    >>
    >> > It won't return with EINTR if your OS is POSIX-compliant.

    >>
    >> 'Officially' this is implementation defined. It is not uncommon for
    >> both select and poll to always return with an 'was interrupted' error
    >> code, because restarting the call with the original timeout after some
    >> time has already passed is not really sensible.

    >
    > The OS is Linux 2.6.xx, so what is the answer? Thank you. Usually, I
    > prefer to install a signal handler with SA_RESTART always enabled
    > ( excpet for SIGALARM hander ), since I's tedious to process EINTR
    > returns for every read/write operation. Do you think so?



    #include
    #include
    #include

    void handle_alrm(int unused)
    {
    }

    int main(void)
    {
    struct sigaction sa;
    struct timeval tv;
    fd_set fd;
    int rc;

    sigemptyset(&sa.sa_mask);
    sa.sa_flags = SA_RESTART;
    sa.sa_handler = handle_alrm;
    sigaction(SIGALRM, &sa, NULL);

    alarm(3);

    tv.tv_sec = 20;
    tv.tv_usec = 0;

    FD_ZERO(&fd);
    FD_SET(STDIN_FILENO, &fd);

    rc = select(1, &fd, NULL, NULL, &tv);
    if (rc == -1) perror("select");

    return 0;
    }

    At least here, this returns EINTR.

  8. Re: Will SA_RESTART affect behavior of select(2) ?

    Rainer Weikusat wrote:
    > Terry writes:
    >> Rainer Weikusat wrote:
    >>
    >>> because restarting the call with the original timeout after some
    >>> time has already passed is not really sensible.

    >> Yes, but, won't select like system call handle the timeout issue
    >> automatically upon restarting from interruption ?

    >
    > Why do you think I wrote that it won't?


    Hopefully, I was expecting your response with reference or evidence. I
    think handling the timeout issue is trivial to implement inside select
    like system call.

  9. Re: Will SA_RESTART affect behavior of select(2) ?

    Rainer Weikusat wrote:
    >
    > #include
    > #include
    > #include
    >
    > void handle_alrm(int unused)
    > {
    > }
    >
    > int main(void)
    > {
    > struct sigaction sa;
    > struct timeval tv;
    > fd_set fd;
    > int rc;
    >
    > sigemptyset(&sa.sa_mask);
    > sa.sa_flags = SA_RESTART;
    > sa.sa_handler = handle_alrm;
    > sigaction(SIGALRM, &sa, NULL);
    >
    > alarm(3);
    >
    > tv.tv_sec = 20;
    > tv.tv_usec = 0;
    >
    > FD_ZERO(&fd);
    > FD_SET(STDIN_FILENO, &fd);
    >
    > rc = select(1, &fd, NULL, NULL, &tv);
    > if (rc == -1) perror("select");
    >
    > return 0;
    > }
    >
    > At least here, this returns EINTR.


    Yeah, you're right. I've modified yours and tried it too.

    #include
    #include
    #include
    #include
    #include
    #include
    #include

    void handle_alrm(int unused)
    {
    }

    int main(void)
    {
    struct sigaction sa;
    struct timeval tv;
    int rc;

    sigemptyset(&sa.sa_mask);
    sa.sa_flags = SA_RESTART;
    sa.sa_handler = handle_alrm;
    sigaction(SIGINT, &sa, NULL);


    tv.tv_sec = 20;
    tv.tv_usec = 0;

    pid_t pid=fork();
    if(pid==0){
    sleep(3);
    kill(getppid(), SIGINT);

    sleep(3);
    kill(getppid(), SIGINT);
    }else{
    /* select is still interrupted */
    rc = select(0, NULL, NULL, NULL, &tv);
    if (rc == -1) perror("select");

    /* open is not interrupted */
    mkfifo("/tmp/xx", 0666);
    rc = open("/tmp/xx", O_RDONLY);
    if (rc == -1) perror("open");
    return 0;
    }
    }

  10. Re: Will SA_RESTART affect behavior of select(2) ?

    On May 26, 6:12 pm, Rainer Weikusat wrote:
    > Steven Woody writes:
    > > On May 26, 4:41 pm, Rainer Weikusat wrote:
    > >> Terry writes:
    > >> > Steven Woody wrote:

    >
    > >> >> If I installed a singal handler with SA_RESTART flag enabled, will a
    > >> >> following select(2) possiblly return with EINTR?

    >
    > >> > It won't return with EINTR if your OS is POSIX-compliant.

    >
    > >> 'Officially' this is implementation defined. It is not uncommon for
    > >> both select and poll to always return with an 'was interrupted' error
    > >> code, because restarting the call with the original timeout after some
    > >> time has already passed is not really sensible.

    >
    > > The OS is Linux 2.6.xx, so what is the answer? Thank you. Usually, I
    > > prefer to install a signal handler with SA_RESTART always enabled
    > > ( excpet for SIGALARM hander ), since I's tedious to process EINTR
    > > returns for every read/write operation. Do you think so?

    >
    > #include
    > #include
    > #include
    >
    > void handle_alrm(int unused)
    > {
    >
    > }
    >
    > int main(void)
    > {
    > struct sigaction sa;
    > struct timeval tv;
    > fd_set fd;
    > int rc;
    >
    > sigemptyset(&sa.sa_mask);
    > sa.sa_flags = SA_RESTART;
    > sa.sa_handler = handle_alrm;
    > sigaction(SIGALRM, &sa, NULL);
    >
    > alarm(3);
    >
    > tv.tv_sec = 20;
    > tv.tv_usec = 0;
    >
    > FD_ZERO(&fd);
    > FD_SET(STDIN_FILENO, &fd);
    >
    > rc = select(1, &fd, NULL, NULL, &tv);
    > if (rc == -1) perror("select");
    >
    > return 0;
    >
    > }
    >
    > At least here, this returns EINTR.


    Thank you. This answered my question

+ Reply to Thread