RE: select() - Linux vs. BSD
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: select() - Linux vs. BSD
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select() - Linux vs. BSD
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 [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: select() - Linux vs. BSD
> > [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 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select() - Linux vs. BSD
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 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 [EMAIL PROTECTED] 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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select() - Linux vs. BSD
[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 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select() - Linux vs. BSD
[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 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select() - Linux vs. BSD
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 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 [EMAIL PROTECTED] 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? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: select() - Linux vs. BSD
[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 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select() - Linux vs. BSD
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 [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select() - Linux vs. BSD
> 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 "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select() - Linux vs. BSD
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 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 [EMAIL PROTECTED] 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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select() - Linux vs. BSD
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select() - Linux vs. BSD
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select() - Linux vs. BSD
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 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 [EMAIL PROTECTED] 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? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select() - Linux vs. BSD
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 unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select() - Linux vs. BSD
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 (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select() - Linux vs. BSD
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 (619) 725-0771 --- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select() - Linux vs. BSD
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 [EMAIL PROTECTED] 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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select() - Linux vs. BSD
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select() - Linux vs. BSD
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, ) 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
[EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
select() - Linux vs. BSD
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
select() - Linux vs. BSD
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select() - Linux vs. BSD
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 [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select() - Linux vs. BSD
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select() - Linux vs. BSD
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 [EMAIL PROTECTED] 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? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
