How do I handle EINTR status
Posted on 1998-07-16
Hi guys, gals and any others :-) out there, I have a 'C' based routine writing records to a pipe. This routine is part of a dynalink library linked in at run time to a "host utility program". The "host utility program" reads records from a data base and passes each record to my routine one at a time for some processing (i.e. writing them to the pipe). I have no access to the internals or the source code of the "host utility". The host utility is a database export utility (called fastexport) for the Teradata RDBMS my dynalink library is refered to as an OUTMOD in Teradata parlance.
My problem is that every now and then (maybe once in a million records processed) I get the EINTR result back from the write system call. The call fails (because of the EINTR) but if i simply retry the call then no problem for another million records or so (figures are highly variable it could go 10 million records or more without error smallest # of records was about 100K before EINTR). The record format is always the same. For what it is worth the pipe is a named pipe opened with the open system call and the O_WRONLY flag. The reader process opens the pipe with the O_RDONLY flag set on the open system call.
I have some basic understanding of what an EINTR means from my University days but can't find any doco on it in any of the unix man pages (other than the really helpful :-) #define statement in errno.h). So, my questions are:
* when I get the EITNR, how do i handle it (I assume it is unwise to simply ignore it without at least understanding why it is occuring)?
* Is it possible to determine what the interrupt was that occured during the system call (to help understand why it is happening)?
* Is the interrupt it is referring to a signal (again can you determine which one)?
* If i determine that the interrupt is something that the host utility is trying to handle is there a way to "raise" the signal from my dynalink routine back to the host utility?
* If none of the above questions hints at this one, what is Unix trying to tell me? i.e. is it trying to tell me that a system wide interrupt occured (eg a timer tick) during my system call and Unix is trying to tell me that it dealt with it - i find this unlikely? Or is unix trying to tell me that a signal i (or the host utility) has requested to handle had fired whilst stuck in the system call and as a result, Unix couldn't invoke my handler because it was in the middle of the system call?