Re: FD_ISSET -- select -- bug?? need help.

[doc]

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 = 50;
 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]

Re: FD_ISSET -- select -- bug?? need help.

[Glynn Clements]

Henrik Nordstrom wrote:

 Glynn Clements wrote:
 
  I don't think that you should use select() on descriptors which are
  non-blocking. You would normally either use select() or non-blocking
  I/O, but not both.
 
 I have to disagree here. Using select is REQUIRED when doing
 non-blocking I/O. There is no other method for waiting until data is
 available (or check which filedescriptors that have data waiting if you
 are using a zero timeout).

Using select() is required if you only want to read from a descriptor
when there is data available (e.g. because the read() would otherwise
block).

If the descriptor is non-blocking (O_NONBLOCK), read() will return -1
and set errno to EAGAIN. You don't need to check whether data is
available in order to prevent blocking.

-- 
Glynn Clements [EMAIL PROTECTED]

Re: FD_ISSET -- select -- bug?? need help.

[Bug Hunter]

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 = 50;
  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]