experienced opinions
in [Unix Programming]
|
From: David Schwartz on 30 Apr 2010 11:04 On Apr 30, 5:41 am, boltar2...(a)boltar.world wrote: > OTOH with poll you have to manually maintain the array of pollfd structures > you're passing in. With select you can let the FD_ macros do all the work for > you. I honestly don't see how there's any difference. You have to call the FD_ macros. The only reason you need the FD_ macros is because the memory format of the structures is not specified. Being forced to interact with the structures through the narrow interface of the macros is, IMO, a limitation of 'select'. > Unless you hard code the array size then any efficiency gains you > get through using poll() you'll soon lose by having to use a vector<> or > realloc() That presents two false alternatives. There are many other possible solutions. For example, you can reallocate the array only when the highest-numbered file descriptor you've ever handled increases. You can expand the array by, say, 16 entries when that happens and never decrease it. This will have no measurable effect on efficiency and doesn't require any hard coded size. > Also poll doesn't return the amount of time left if in timeout mode and > something happens unlike select. You mean "unlike what my implementation of 'select' happens to do". For example, SuSv2 says only "On successful completion, the object pointed to by the timeout argument may be modified." That doesn't sound all that useful to me. DS
From: Bill Cunningham on 30 Apr 2010 12:19 boltar2003(a)boltar.world wrote: > On Fri, 30 Apr 2010 14:29:44 +0200 > Rainer Weikusat <rweikusat(a)mssgmbh.com> wrote: > Also poll doesn't return the amount of time left if in timeout mode > and something happens unlike select. So you would say go with select() then? I'm certainly not knowledgable enough to do anything manually here. I'm going to log into my server with telnet. I know there's that timeval struct with poll(). Bill
From: Chris Friesen on 30 Apr 2010 12:51 On 04/29/2010 07:56 PM, David Schwartz wrote: > I recommend using 'poll' for two reasons. > Second, it doesn't become inefficient when the descriptor index is > large. Due to the way the 'select' sets are composed, 'select'ing on > higher-numbered descriptors is less efficient and can get you into > trouble depending on how the C library was compiled. While it handles large indexes better than select, poll still becomes inefficient when the total number of descriptors is large. For really high-performance servers that need to deal with large numbers (tens of thousands) of descriptors, POSIX doesn't really have a solution. Various OS-specific options exist (kqueue on BSD, epoll on Linux, /dev/epoll on Solaris, etc.) Chris
From: Bill Cunningham on 30 Apr 2010 13:35 Rainer Weikusat wrote: > I always use poll because I consider the interface to be saner. [...] What I am seeing is that I'm going to need a recv() and send() somewhere too and a loop. Maybe more than one. I have purchased the Stevens book "Unix network programming" in hopes that that will help. Alas buying books just to go out of date is not my number 1 idea. I was hoping for internet tutorials or wikis. Bill
From: David Schwartz on 30 Apr 2010 16:57
On Apr 30, 9:51 am, Chris Friesen <cbf...(a)mail.usask.ca> wrote: > While it handles large indexes better than select, poll still becomes > inefficient when the total number of descriptors is large. Only if comparatively few of the descriptors are active. The cost of a call to 'poll' is roughly O(n). If the number of descriptors discovered ready is usually one, that sucks. But if the number of descriptors discovered per call is also O(n), then its efficiency does not go down as the number of descriptors goes up. In fact, with more descriptors, the amount of time between calls to 'poll' goes up. If you assume the amount of network activity is constant, that means more descriptors discovered per call to 'poll'. This means 'poll' actually becomes more efficient as the number of descriptors goes up. (If, and only if, your access pattern is like this one.) However, the worst-case behavior of 'select' and 'poll' are pretty awful. > For really high-performance servers that need to deal with large numbers > (tens of thousands) of descriptors, POSIX doesn't really have a > solution. Various OS-specific options exist (kqueue on BSD, epoll on > Linux, /dev/epoll on Solaris, etc.) And many of these techniques outperform 'select' or 'poll' even when the number of descriptors is small, so the only downside is usually added implementation complexity. Also important, the worst-case behavior of these mechanisms is *way* better than 'select' or 'poll'. If you typically have a small number of active descriptors and a large number of inactive descriptors, you need to implement these high- performance mechanisms. DS |