[ic] EINTR on select

Steffen Dettmer interchange-users@interchange.redhat.com
Fri Dec 7 18:47:00 2001


* Javier Martin wrote on Fri, Dec 07, 2001 at 17:02 +0100:
> > > My question is: Is it possible that the interchange process receive any
> > > asynchronous signal that could break ongoing system calls such
> > as select?

You can test it by sending a lot of signals. Well, you need some
"unused" signal for that, and IIRC it must be handled. I do not
know, but maybe you can try:

#dummy
$SIG{USR1} = sub {  }; 


and then kill -USR1 $PID many times. AFAIK this test "breaks"
really much services :)

> > Did you see any message about 'select' from the error.log of IC? If yes,
> > can you post that part of message?
> 
> No. Interchange does not complain at all. It's my code which breaks on
> signal reception.

You should call select(2) in a 
do {} while (ret == 1 && errno == EINTR);
BTW, since you cannot rely on select return value for tm on most
systems, you need to use gettimeofday() or something which makes
a correct time select code slightly more complex... Same of
course for reads and writes. Well, and since things like print
sometimes call write, you can have some strange results anyway.
If you send i.e. 1000 signals per second, I don't think that any
non-bullet-proof process will work reliable... But signals
usually don't came without reason. I had such a problem with a
SIGCHLD in some server, difficult to handle such things.

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.