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");
            	  }
                }

Originally Posted by mynickmynick

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.

Originally Posted by brewbuck

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

Originally Posted by brewbuck

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

Originally Posted by mynickmynick

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

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 %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)

Originally Posted by matsp

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??

Originally Posted by mynickmynick

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