> 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 effici
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
Us
>
> [EMAIL PROTECTED] 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.
>
> Wh
On Sat, 2 Jun 2001, Jamie Lokier wrote:
> [EMAIL PROTECTED] 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 in
[EMAIL PROTECTED] 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
> 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
-
To unsubscribe from this list: send the line "unsubscrib
On Fri, 1 Jun 2001 [EMAIL PROTECTED] 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 interes
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
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 [EMAIL PROTECTED]
Software Engineer
Compendium Technologies, Inc
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 mo
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 wri
> 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 enhanceme
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
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 e
14 matches
Mail list logo
