Thread: select and EINTR

  1. #1
    Alessio Stella
    Join Date
    May 2008
    Location
    Italy, Bologna
    Posts
    251

    select and EINTR

    On an embedded vision system prototype I am developing, using Linux kernel 2.6.18
    the following socket server code extract
    Code:
                  read_fd_set = active_fd_set;  
    
                  if(select (FD_SETSIZE, &read_fd_set, NULL, NULL, NULL) < 0)
                    {
                      perror ("select");
                      exit (EXIT_FAILURE);
                    }
    gave me the following problem

    select: Interrupted system call

    appereantly the thread died cause select was interrupted by a signal (might be a signal used by camera API??)

    I have two questions:
    (1)
    why if I perform exit() not all the threads die?? POSIX says that whenever a thread performs exit() all processes should die!
    (2)
    Is the following a good correction or do I risk to loose some client request if a signal arrives in the mean time??
    Code:
                  read_fd_set = active_fd_set;    	   
                  while (select (FD_SETSIZE, &read_fd_set, NULL, NULL, NULL) < 0)
                    {
                	  if (errno!=EINTR)
                	  {
                		  //checked that errno is on a per thread basis
    	                  perror ("select");
    	                  exit (EXIT_FAILURE);
                	  }
                	  else 
                	  {
                		  perror("select");
                		  printf("Reselecting\n");
                	  }
                    }

  2. #2
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by mynickmynick View Post
    I have two questions:
    (1)
    why if I perform exit() not all the threads die?? POSIX says that whenever a thread performs exit() all processes should die!
    I believe that's true, and it should be the case. What evidence do you have that not all the threads are terminating?

    (2)
    Is the following a good correction or do I risk to loose some client request if a signal arrives in the mean time??
    There is no race condition in the code you posted -- it looks correct. But I would not bother reporting the "error" since a system call being interrupted by a signal is not really an error condition, it's just a normal UNIX event. If you get an error return and errno is EINTR, just restart the loop as if nothing happened.

    In fact, many UNIX system calls can be interrupted by signals, and you should generally always check for EINTR and retry the system call.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  3. #3
    Alessio Stella
    Join Date
    May 2008
    Location
    Italy, Bologna
    Posts
    251
    Quote Originally Posted by brewbuck View Post
    I believe that's true, and it should be the case. What evidence do you have that not all the threads are terminating?
    the fact is that the program is run by the console and does not terminate
    the prompt does not appear
    I have to kill it by another shell


    Quote Originally Posted by brewbuck View Post
    In fact, many UNIX system calls can be interrupted by signals, and you should generally always check for EINTR and retry the system call.
    I agree It was only for debug purpouse

  4. #4
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by mynickmynick View Post
    the fact is that the program is run by the console and does not terminate
    the prompt does not appear
    I have to kill it by another shell
    Are you catching any signals? If you ignore certain signals, then exiting may not work...

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  5. #5
    Alessio Stella
    Join Date
    May 2008
    Location
    Italy, Bologna
    Posts
    251
    what I get is at the beginning
    ~/_My/Server/Stella/Prototype/Release# ps -auroot -T -o sched,policy,rtprio,pid,cmd,spid,pcpu --sort policy
    SCH POL RTPRIO PID CMD SPID &#37;CPU
    ..
    ..
    1 FF 1 5384 ./Prototype 5384 0.5 (my thread)
    0 TS - 5384 ./Prototype 5385 0.0 (API thread)
    1 FF 10 5384 ./Prototype 5386 0.0 (API thread)
    1 FF 2 5384 ./Prototype 5388 0.0 (my thread)
    1 FF 2 5384 ./Prototype 5389 0.0 (my thread)
    1 FF 2 5384 ./Prototype 5390 0.0 (my thread)
    1 FF 99 5384 ./Prototype 5391 0.0 (API thread)
    1 FF 99 5384 ./Prototype 5392 0.0(API thread)
    1 FF 99 5384 ./Prototype 5393 0.0(API thread)


    after I have
    select: Interrupted system call
    and the process hangs in one shell
    i do again in the other shell and obtain:
    ~/_My/Server/Stella/Prototype/Release# ps -auroot -T -o sched,policy,rtprio,pid,cmd,spid,pcpu --sort policy
    SCH POL RTPRIO PID CMD SPID %CPU
    ..
    ..
    1 FF 1 5384 ./Prototype 5384 0.0
    1 FF 2 5384 ./Prototype 5388 0.0
    1 FF 2 5384 ./Prototype 5389 0.0
    1 FF 2 5384 ./Prototype 5390 0.0
    1 FF 99 5384 ./Prototype 5391 0.0
    1 FF 99 5384 ./Prototype 5392 0.0
    1 FF 99 5384 ./Prototype 5393 0.0

    so only two threads die
    and they are (I can tell cause I recognize them by sched policy and priority)
    two threads of the Camera API (threads I did not program myself)
    Last edited by mynickmynick; 07-24-2008 at 09:55 AM.

  6. #6
    Alessio Stella
    Join Date
    May 2008
    Location
    Italy, Bologna
    Posts
    251
    Quote Originally Posted by matsp View Post
    Are you catching any signals? If you ignore certain signals, then exiting may not work...

    --
    Mats
    might be the API threads (of which I do not have the code) catches the signal used to perform exit communication to all threads??
    how can I debug this??

  7. #7
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by mynickmynick View Post
    might be the API threads (of which I do not have the code) catches the signal used to perform exit communication to all threads??
    how can I debug this??
    Well, I don't know what access you have to the API threads, and what they may do to signals. But it's one possible scenario that you would have to explore.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. SIGABRT upon free()
    By registering in forum C Programming
    Replies: 2
    Last Post: 07-19-2003, 07:52 AM