Thursday, September 27, 2007

POSIX Thread, Select & Poll

The model of simply using one thread per connection, while simpler to code and support,
is viable for only a few to several hundred (possibly a few thousand) threads.

From a performance perspective, select(3C) has stated in the man page (from circa Solaris 2.6 days IIRC) "poll(2) function is preferred over this function." select(3C) in Solaris is very inefficient as it has to translate in user space from the bitfields and calls poll() to do the kernel work anyway. Not to mention that recompiling an application that uses select(3C) as a 64 bit binary can result in a 500% performance drop. This occurs if they do not modify FD_SETSIZE, as this goes from 1024 in 32 bit compiles to 65536 in 64 bit compiles. So avoid select like the plague if performance is at an issue for your application. Select has been implemented as a direct syscall in several other Unix versions so code calling select(3C) will likely underperform on Solaris compared to other OSs.

Even poll(2) suffers a lot of unnecessary performance degredation issues so, if dealing with thousands of descriptors, the far more scalable /dev/poll "man -s 7d poll" or Event Completion
Framework should be used. Here's an article wrote back in 2002 comparing scalability of
poll(2) and /dev/poll :

http://developers.sun.com/solaris/articles/polling_efficient.html

And it seems /dev/poll has been considered a bit too complicated for a lot of real world uses, and also suffers some performance issues in cases of quickly changing lists of file descriptors to
monitor, so the even newer Event Completion Framework/Ports have been created to deal with both issues :

http://developers.sun.com/solaris/articles/event_completion.html
http://partneradvantage.sun.com/protected/solaris10/adoptionkit/tech/tecf.html

Both /dev/poll and Event Ports have been ported to Linux, so, whether they are POSIX standards, extentions, or just de facto standards since they are the only tools to do the job if the state of many thousands of connections must be polled, they must be considered.

No comments: