Re: select() - Linux vs. BSD

Re: select() - Linux vs. BSD

[Andries.Brouwer]

    On Tue, 29 May 2001, John Chris Wren wrote:

    >     In BSD, select() states that when a time out occurs,
    >     the bits passed to select will not be altered.
    >     In Linux, which claims BSD compliancy for this
    >     in the man page (but does not state either way
    >     what will happen to the bits), zeros the users bit masks
    >     when a timeout occurs.

(i) "In BSD" - which one did you look at? 4.2? 4.3? 4.4?
Details differ a bit.

(ii) The Linux man page only says

RETURN VALUE
       On  success,  select  and  pselect  return  the  number of
       descriptors contained in the descriptor sets, which may be
       zero  if  the  timeout expires before anything interesting
       happens.  On error, -1  is  returned,  and  errno  is  set
       appropriately;  the  sets and timeout become undefined, so
       do not rely on their contents after an error.
	
That is, a wise programmer does not assume any particular value
for the bits after a timeout.

    >     Should the man pages be changed to reflect reality,

They do reflect reality.

    > or select() fixed to act like BSD?

No, select() is fine.


dean gaudet answered:

    sounds like a man page bug.

Shame on him for noticing man page bugs without cc'ing
the man page maintainer! Fortunately however, I do not
think anything is wrong here. But just to be sure I added
a sentence to select.2:

  On BSD, when a timeout occurs, the file descriptor bits are not changed.
  Linux follows SUSv2 and sets the bit masks to zero upon a timeout.

Andries

Re: select() - Linux vs. BSD

[lost]

On Fri, 1 Jun 2001 Andries.Brouwer@cwi.nl wrote:

> (ii) The Linux man page only says
> 
> RETURN VALUE
>        On  success,  select  and  pselect  return  the  number of
>        descriptors contained in the descriptor sets, which may be
>        zero  if  the  timeout expires before anything interesting
>        happens.  On error, -1  is  returned,  and  errno  is  set
>        appropriately;  the  sets and timeout become undefined, so
>        do not rely on their contents after an error.
> 	
> That is, a wise programmer does not assume any particular value
> for the bits after a timeout.

So how does this say the value of the fdsets are undefined after a
timeout? It says specifically that upon success it returns the number of
descriptors in the sets, zero if the timeout expires. That is a success
condition upon which select() sets the fdsets to contain the descriptors
upon which something interesting happened. In the case of a timeout with
no descriptor having anything interesting, the sets would, logically, be
cleared.

The man page does state that the value of "timeout" is effectively
undefined upon return and that "timeout" and the fdsets are undefined
after an error, however.

Of course, not looking at the sets upon a zero return is a fairly obvious
optimization as there is little point in doing so.

William Astle
finger lost@l-w.net for further information

Geek Code V3.12: GCS/M/S d- s+:+ !a C++ UL++++$ P++ L+++ !E W++ !N w--- !O
!M PS PE V-- Y+ PGP t+@ 5++ X !R tv+@ b+++@ !DI D? G e++ h+ y?

Re: select() - Linux vs. BSD

[Jamie Lokier]

lost@l-w.net wrote:
> Of course, not looking at the sets upon a zero return is a fairly obvious
> optimization as there is little point in doing so.

No; a fairly obvious optimisation is to avoid calling FD_ZERO if you
can clear the bits individually when you test them.

When you examine the sets, you can clear each bit that you examine and
then you know you have a zero set.  Then you can set only the relevant
bits for the next call to select().

If you can't rely on the sets being cleared on a timeout, then you
will have to call FD_ZERO in that case, or you will have to go through
the list of descriptors and clear them individually.  (This can be
avoided but it means keeping track of state between successive calls
to select()).  This is contrary to the non-timeout case, where you
stop checking bits when you have counted N of them set.

So you see, there is a handy optimisation if you can assume the sets
are zeroed on timeout.

-- Jamie

Re: select() - Linux vs. BSD

[lost]

On Sat, 2 Jun 2001, Jamie Lokier wrote:

> lost@l-w.net wrote:
> > Of course, not looking at the sets upon a zero return is a fairly obvious
> > optimization as there is little point in doing so.
> 
> No; a fairly obvious optimisation is to avoid calling FD_ZERO if you
> can clear the bits individually when you test them.

That would make sense. HOWEVER, you took my comment out of context. I had
pointed out that since the zero return from select() is not an error
condition, you can rely on the sets being zeroed out. The zero simply
indicates that no descriptors had anything interesting occur and if the
sets are not zeroed, the implementation is broken. Upon error, the values
are undefined and the value of timeout is undefined. (In this case, doing
nothing upon a zero return from select() is perfectly reasonable.)

If I recall, the original posting was about whether the sets were zeroed
upon an error condition which a timeout is not defined as in this case.


William Astle
finger lost@l-w.net for further information

Geek Code V3.12: GCS/M/S d- s+:+ !a C++ UL++++$ P++ L+++ !E W++ !N w--- !O
!M PS PE V-- Y+ PGP t+@ 5++ X !R tv+@ b+++@ !DI D? G e++ h+ y?

RE: select() - Linux vs. BSD

[John Chris Wren]

>
> lost@l-w.net wrote:
> > Of course, not looking at the sets upon a zero return is a
> fairly obvious
> > optimization as there is little point in doing so.
>
> No; a fairly obvious optimisation is to avoid calling FD_ZERO if you
> can clear the bits individually when you test them.
>
> When you examine the sets, you can clear each bit that you examine and
> then you know you have a zero set.  Then you can set only the relevant
> bits for the next call to select().
>
> If you can't rely on the sets being cleared on a timeout, then you
> will have to call FD_ZERO in that case, or you will have to go through
> the list of descriptors and clear them individually.  (This can be
> avoided but it means keeping track of state between successive calls
> to select()).  This is contrary to the non-timeout case, where you
> stop checking bits when you have counted N of them set.
>
> So you see, there is a handy optimisation if you can assume the sets
> are zeroed on timeout.
>

I would have said just the opposite.  That if it you have a large number of
handles you're waiting on, and you have to go back through and set the bits
everytime you timeout that you would incur a larger overhead.  From the
perspective of my application, it would have been more efficient to not zero
them (I was waiting on a number of serial channels, and the timeout was used
to periodically pump more data to the serial channel.  When I received data,
I buffered it, and another thread took care of processing it).

It all really depends on the coding style of your program, and what you need
to do on a timeout.  Certain types of applications would benefit from
non-zero'ing, others from zeroing.

All what is *most* important is that the behavior is clearly understood and
well documented.  A google search made it pretty clear that it was a source
of confusion.

--John

Re: select() - Linux vs. BSD

[Mike Castle]

On Sat, Jun 02, 2001 at 10:47:49PM -0400, John Chris Wren wrote:
> I would have said just the opposite.  That if it you have a large number of
> handles you're waiting on, and you have to go back through and set the bits
> everytime you timeout that you would incur a larger overhead.  From the

Use a temp fd_set and assignment.

fd_set readset;

readset=set_to_watch

select(n, readset, NULL, NULL, timeout);

mrc
-- 
     Mike Castle      dalgoda@ix.netcom.com      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

RE: select() - Linux vs. BSD

[David Schwartz]

> I would have said just the opposite.  That if it you have a large
> number of
> handles you're waiting on, and you have to go back through and
> set the bits
> everytime you timeout that you would incur a larger overhead.  From the
> perspective of my application, it would have been more efficient
> to not zero
> them (I was waiting on a number of serial channels, and the
> timeout was used
> to periodically pump more data to the serial channel.  When I
> received data,
> I buffered it, and another thread took care of processing it).

	The usual implementation is you have a 'permanent' fd_set and a 'temporary'
fd_set. Before each call to select, you memcpy the permanent fd_set into the
temporary and pass the temporary to select. If you wish to stop selecting
for read or write on a given socket, you remove it from the appropriate
permanent set. This way you don't have to twiddle too many bits.

	DS

Re: select() - Linux vs. BSD

[Andries.Brouwer]

> So how does this say the value of the fdsets are undefined
> after a timeout?

You are right, it doesn't say so. I should have said
  That is, a wise programmer does not assume any particular value
  for the bits after an error.

Andries

select() - Linux vs. BSD

[John Chris Wren]

	I hope I'm not rehashing anything discussed before, but I couldn't find any
references to this:

	In BSD, select() states that when a time out occurs, the bits passed to
select will not be altered.  In Linux, which claims BSD compliancy for this
in the man page (but does not state either way what will happen to the
bits), zeros the users bit masks when a timeout occurs.  I have written a
test case, and run on both systems; BSD behaves as stated, Linux does not
act like BSD.

	Should the man pages be changed to reflect reality, or select() fixed to
act like BSD?

	-- John

Re: select() - Linux vs. BSD

[Mike Castle]

On Tue, May 29, 2001 at 11:55:24AM -0400, John Chris Wren wrote:
> select will not be altered.  In Linux, which claims BSD compliancy for this
> in the man page (but does not state either way what will happen to the
> bits), zeros the users bit masks when a timeout occurs.  I have written a

Where in the man page does it state this?  I just read it and couldn't find
any such statement.

I do, however, find the following:

       exceptfds will be watched for exceptions.   On  exit,  the
       sets  are  modified in place to indicate which descriptors
       actually changed status.


If there is a time out, it makes sense that no descriptors changed state,
and so everything would be zeroed out.

And actually, the example seems to support this:

           if (retval)
               printf("Data is available now.\n");
               /* FD_ISSET(0, &rfds) will be true. */

The comment seems to indicate that if retval is 0, then FD_ISSET will be
false.

mrc
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  dalgoda@ix.netcom.com  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

Re: select() - Linux vs. BSD

[Alan Cox]

> 	In BSD, select() states that when a time out occurs, the bits passed to
> select will not be altered.  In Linux, which claims BSD compliancy for this

Nope. BSD manual pages (the authentic ones anyway) say that the timeout value
may well be written back but that this was a future enhancement and that users
shoulsnt rely on the value being unchanged.

> in the man page (but does not state either way what will happen to the
> bits), zeros the users bit masks when a timeout occurs.  I have written a
> test case, and run on both systems; BSD behaves as stated, Linux does not
> act like BSD.
> 
> 	Should the man pages be changed to reflect reality, or select() fixed to
> act like BSD?

BSD should stop changing its mind if its changed its man pages

Re: select() - Linux vs. BSD

[lost]

On Tue, 29 May 2001, Alan Cox wrote:

> > 	In BSD, select() states that when a time out occurs, the bits passed to
> > select will not be altered.  In Linux, which claims BSD compliancy for this
> 
> Nope. BSD manual pages (the authentic ones anyway) say that the timeout value
> may well be written back but that this was a future enhancement and that users
> shoulsnt rely on the value being unchanged.

The reference was to the fdsets passed in if I read the original post
correctly.

William Astle
finger lost@l-w.net for further information

Geek Code V3.12: GCS/M/S d- s+:+ !a C++ UL++++$ P++ L+++ !E W++ !N w--- !O
!M PS PE V-- Y+ PGP t+@ 5++ X !R tv+@ b+++@ !DI D? G e++ h+ y?

Re: select() - Linux vs. BSD

[dean gaudet]

On Tue, 29 May 2001, John Chris Wren wrote:

> 	In BSD, select() states that when a time out occurs, the bits passed to
> select will not be altered.

from the single unix standard:

	On failure, the objects pointed to by the readfds, writefds,
	and errorfds arguments are not modified. If the timeout interval
	expires without the specified condition being true for any of
	the specified file descriptors, the objects pointed to by the
	readfds, writefds, and errorfds arguments have all bits set to 0.

> 	Should the man pages be changed to reflect reality, or select() fixed to
> act like BSD?

sounds like a man page bug.

-dean

Re: select() - Linux vs. BSD

[Dr. Kelsey Hudson]

On Tue, 29 May 2001, John Chris Wren wrote:

> 	Should the man pages be changed to reflect reality, or select() fixed to
> act like BSD?
>

BSD should be destroyed :)

 Kelsey Hudson                                           khudson@ctica.com
 Software Engineer
 Compendium Technologies, Inc                               (619) 725-0771
---------------------------------------------------------------------------