Loco
07-24-2002, 05:51 PM
Taken from the original FAQ.
2.14 - Whats the difference between select() and poll()?
From Richard Stevens:
The basic difference is that select()'s fd_set is a bit mask and therefore has some fixed size. It would be possible for the kernel to not limit this size when the kernel is compiled, allowing the application to define FD_SETSIZE to whatever it wants (as the comments in the system header imply today) but it takes more work. 4.4BSD's kernel and the Solaris library function both have this limit. But I see that BSD/OS 2.1 has now been coded to avoid this limit, so it's doable, just a small matter of programming. :-) Someone should file a Solaris bug report on this, and see if it ever gets fixed. [Ed. Note - This was fixed in Solaris 7 - see below.]
With poll(), however, the user must allocate an array of pollfd structures, and pass the number of entries in this array, so there's no fundamental limit. As Casper notes, fewer systems have poll() than select, so the latter is more portable. Also, with original implementations (SVR3) you could not set the descriptor to -1 to tell the kernel to ignore an entry in the pollfd structure, which made it hard to remove entries from the array; SVR4 gets around this. Personally, I always use select() and rarely poll(), because I port my code to BSD environments too. Someone could write an implementation of poll() that uses select(), for these environments, but I've never seen one. Both select() and poll() are being standardized by POSIX 1003.1g.
Colm Smyth (Colm.Smyth@Sun.COM) writes:
I thought you might be interested to know that this was resolved in Solaris 7; here is an extract from the select(3C) man-page:
NOTES
The default value for FD_SETSIZE (currently 1024) is larger than the default limit on the number of open files. To accommodate 32-bit applications that wish to use a larger number of open files with select(), it is possible to increase this size at compile time by providing a larger definition of FD_SETSIZE before the inclusion of . The maximum supported size for FD_SETSIZE is 65536. The default value is already 65536 for 64-bit applications.
neter
Joined: 01 Aug 2002
Posted: Mon Aug 05, 2002 6:24 am Post subject: Poll vs Select
Interesting paper on why poll is a more robust solution than select:
http://www.west.nl/whitepapers/netwprog/network_programming.html
Since reading that (and never liking the nfds concept of select) I've changed much of my code to use poll. Definitely more elegant imho.
-neter
Loco
Site Admin
Posted: Mon Aug 05, 2002 10:03 am Post subject: Good information
Neter,
Good information. I will put a link to it in the UNIX Socket FAQ.
However, there are a lot of issues that must be taken in account in order to decide which one is better, not just the number of file descriptors that can be selected/polled.
In fact, I don't think one of them is better than the other, I just think they have different approaches and may suit different needs.
One drawback of poll() is how to handle dynamic connections, that is, a server that receives new connections constantly and closes connections constantly, keeping the array compact after a while is not so easy.
Well, in fact I don't see this as a problem:
Growing or shrinking the array is not difficult using malloc()/realloc().
I would not shrink the array, I'd just grow it when neeeded. For example, suppose we have N connections (sockets) and in the loop we detect a socket has been closed by the remote peer, its index is I.
The code would move the Nth element (element[N-1]) to the Ith position, and then decrement the element counter. New connections would be added to the end of the array if there is available "slots", if there isn't space available in the array it would be expanded via realloc() by some threshold.
It wasn't so bad, was it?
2.14 - Whats the difference between select() and poll()?
From Richard Stevens:
The basic difference is that select()'s fd_set is a bit mask and therefore has some fixed size. It would be possible for the kernel to not limit this size when the kernel is compiled, allowing the application to define FD_SETSIZE to whatever it wants (as the comments in the system header imply today) but it takes more work. 4.4BSD's kernel and the Solaris library function both have this limit. But I see that BSD/OS 2.1 has now been coded to avoid this limit, so it's doable, just a small matter of programming. :-) Someone should file a Solaris bug report on this, and see if it ever gets fixed. [Ed. Note - This was fixed in Solaris 7 - see below.]
With poll(), however, the user must allocate an array of pollfd structures, and pass the number of entries in this array, so there's no fundamental limit. As Casper notes, fewer systems have poll() than select, so the latter is more portable. Also, with original implementations (SVR3) you could not set the descriptor to -1 to tell the kernel to ignore an entry in the pollfd structure, which made it hard to remove entries from the array; SVR4 gets around this. Personally, I always use select() and rarely poll(), because I port my code to BSD environments too. Someone could write an implementation of poll() that uses select(), for these environments, but I've never seen one. Both select() and poll() are being standardized by POSIX 1003.1g.
Colm Smyth (Colm.Smyth@Sun.COM) writes:
I thought you might be interested to know that this was resolved in Solaris 7; here is an extract from the select(3C) man-page:
NOTES
The default value for FD_SETSIZE (currently 1024) is larger than the default limit on the number of open files. To accommodate 32-bit applications that wish to use a larger number of open files with select(), it is possible to increase this size at compile time by providing a larger definition of FD_SETSIZE before the inclusion of . The maximum supported size for FD_SETSIZE is 65536. The default value is already 65536 for 64-bit applications.
neter
Joined: 01 Aug 2002
Posted: Mon Aug 05, 2002 6:24 am Post subject: Poll vs Select
Interesting paper on why poll is a more robust solution than select:
http://www.west.nl/whitepapers/netwprog/network_programming.html
Since reading that (and never liking the nfds concept of select) I've changed much of my code to use poll. Definitely more elegant imho.
-neter
Loco
Site Admin
Posted: Mon Aug 05, 2002 10:03 am Post subject: Good information
Neter,
Good information. I will put a link to it in the UNIX Socket FAQ.
However, there are a lot of issues that must be taken in account in order to decide which one is better, not just the number of file descriptors that can be selected/polled.
In fact, I don't think one of them is better than the other, I just think they have different approaches and may suit different needs.
One drawback of poll() is how to handle dynamic connections, that is, a server that receives new connections constantly and closes connections constantly, keeping the array compact after a while is not so easy.
Well, in fact I don't see this as a problem:
Growing or shrinking the array is not difficult using malloc()/realloc().
I would not shrink the array, I'd just grow it when neeeded. For example, suppose we have N connections (sockets) and in the loop we detect a socket has been closed by the remote peer, its index is I.
The code would move the Nth element (element[N-1]) to the Ith position, and then decrement the element counter. New connections would be added to the end of the array if there is available "slots", if there isn't space available in the array it would be expanded via realloc() by some threshold.
It wasn't so bad, was it?