hmmm. I'm not sure that is it. We have abandoned looking at select for
errors for the pipe.
It could be a sigalarm, as the timeout may have tripped. However we are also
using sigalarm, and that code was not executed. And, select did not return a -1,
and there were no errors indicated on the non-pipe handles.
bug
[EMAIL PROTECTED] wrote:
> On Fri, 18 Sep 1998, Bug Hunter wrote:
>
> >
> > We are using a stock redhat 5.1 in an embedded system.
> > It is not on the internet, and has _very_ few services. (for
> > you hacker types).
> >
> > If this is on the wrong list, please point me to a
> > better list. thanks!
> >
> > we opened a pipe without error. we then did this:
> > FD_ZERO(&InputFD); // initialize read
> > descriptors
> >
> > FD_SET(s,&InputFD); // Add
> > socket to descriptors to
> > FD_SET(FromDH,&InputFD); // wait on Modem
> > data as well
> >
> > FD_ZERO(&wErrorFD);
> > FD_SET(s,&wErrorFD);
> > FD_SET(FromDH, &wErrorFD);
> >
> > signal(SIGALRM,SignalHandler);
> >
> > while(1){
> > wInputFD = InputFD;
> > // don't wait more than 500msec before
> > reporting
> > timeout.tv_sec = 0;
> > timeout.tv_usec = 500000;
> > short result =
> > select(FD_SETSIZE,&wInputFD,NULL,&wErrorFD,&timeout);
> > ...
> >
> >
> > We get a 2 from select, then the pipe (FromDH) indicates
> > an error. errno is zero. There is no error that we can
> > see. any clues?
>
> I am not sure, but I think the SIGALARM and select use the same timer.
> If my suposition is true, should be normaly for select to have strange
> behavior when got a interrupt.
>
> Any oppinion ?
>
> ------------------------------------------------------------------------------
> Best wishes,
> Marcel - Titus MARGINEAN
> [EMAIL PROTECTED], [EMAIL PROTECTED]
