What is the difference between polling and selecting

The All event-driven functions tend to make the code more complex, harder to follow and require more code to be written to accomplish the same task as the simple select and poll approaches do. For great benchmarks on network scalability on a few operating systems, see Felix von Leitner's work.

History select was introduced in 4. Speed poll and select are basically the same speed-wise: slow. As soon as you go beyond perhaps a hundred file descriptors or so - of course depending on your CPU and hardware you will start noticing that the mere waiting for file descriptor activity and the following checking which file descriptor that it was, takes a significant time and becomes a bottle neck. Portability select - has existed for a great while and exists almost everywhere.

Lots of early implementations did poll as a wrapper around select. Steven Lu Sasha Sasha. Add a comment. Active Oldest Votes. The select method is rather clunky and inefficient. Improve this answer. Community Bot 1 1 1 silver badge.

Brandon Rhodes Brandon Rhodes This answer makes it sound like epoll is always preferable — user You're making it seem as if the bitscan was the bottleneck. It isn't. Syscalls takes hundreds if not thousands. According to this benchmark I found, they seem about equally as in efficient with large fd sets: monkey.

I think that this answers your question: From Richard Stevens rstevens noao. October Update: The email referenced above is at least as old as ; the poll command is now supported across all modern operating systems - including BSD. When was Stevens answer written? Does the comment about poll not being available on BSD still apply? Rich Stevens passed away in September , so the answer has to be older than that.

I don't believe it. Answer posted 5 years ago, I stumble upon it, leave it open in the browser. On platforms that do not have a native poll implementation, the poll semantics are mapped onto select. With the timeout value, you can specify how long select will wait for an event. If timeout is NULL , select will wait indefinitely for an event. If timeout's timeval structures are set to 0, select will return immediately rather than wait for any event to occur.

Otherwise, timeout defines how long select will wait. SUSv2 indicates that all compliant implementation will support a timeout of at least 31 days. Check out Listing A for a select example. In comparison to select , poll allows a greater degree of flexibility in determining what type of events can be processed. In addition to the read, write, and error notifications, poll also supports explicit recognition of out-of-band and high-priority data.

Unlike select , poll 's timeout is a simple integer that represents how long poll will wait for an event. Changing the value without recompiling the kernel is inadequate. From a portability standpoint, however, beware of using large descriptor sets. The figure below shows the various conditions that are handled by our call to select :. Instead of the function flow being driven by the call to fgets , it is now driven by the call to select.

Our original version in Section 5. This amount of time is one RTT plus the server's processing time which is close to 0 for a simple echo server. We can therefore estimate how long it will take for a given number of lines to be echoed if we know the RTT between the client and server.

We can use ping to measure RTTs. If we consider the network between the client and server as a full-duplex pipe, with requests going from the client to the server and replies in the reverse direction, then the following figure shows our stop-and-wait mode:.

A request is sent by the client at time 0 and we assume an RTT of 8 units of time. The reply sent at time 4 is received at time 7. This stop-and-wait mode is fine for interactive input.

The problem is: if we run our client in a batch mode, when we redirect the input and output, however, the resulting output file is always smaller than the input file and they should be identical for an echo server. To see what's happening, realize that in a batch mode, we can keep sending requests as fast as the network can accept them.

The server processes them and sends back the replies at the same rate. This leads to the full pipe at time 7, as shown below:. Assume that the input file contains only nine lines. The last line is sent at time 8, as shown in the above figure. But we cannot close the connection after writing this request because there are still other requests and replies in the pipe. The cause of the problem is our handling of an EOF on input: The function returns to the main function, which then terminates.

But in a batch mode, an EOF on input does not imply that we have finished reading from the socket; there might still be requests on the way to the server, or replies on the way back from the server. The solution is to close one-half of the TCP connection by sending a FIN to the server, telling it we have finished sending data, but leave the socket descriptor open for reading.

This is done with the shutdown function, described in the next section. When several lines of input are available from the standard input. But, fgets only returns a single line and leaves any remaining data sitting in the stdio buffer. The reason is that select knows nothing of the buffers used by stdio;it will only show readability from the viewpoint of the read system call, not calls like fgets. Thus, mixing stdio and select is considered very error-prone and should only be done with great care.

Instead of data being hidden from select in a stdio buffer, it is hidden in readline 's buffer. In Section 3. But again, the complexity grows out of hand quickly when we have to handle the case where the readline buffer contains a partial line meaning we still need to read more as well as when it contains one or more complete lines which we can consume.

The normal way to terminate a network connection is to call the close function. But, there are two limitations with close that can be avoided with shutdown :.

Typical values for the howto argument that you will encounter will be 0 close the read half , 1 close the write half , and 2 close the read half and the write half.

In the function, select notifies us as soon as the server closes its end of the connection and shutdown lets us handle batch input correctly. We now rewrite the TCP echo server Section 5. Before the first client has established a connection, the server has a single listening descriptor. The only nonzero entry in the descriptor set is the entry for the listening sockets and the first argument to select will be 4.

When the first client establishes a connection with our server, the listening descriptor becomes readable and our server calls accept. The new connected descriptor returned by accept will be 4. The following figure shows this connection:. The server must remember the new connected socket in its client array, and the connected socket must be added to the descriptor set. The updated data structures are shown in the figure below:. The new connected socket which we assume is 5 must be remembered, giving the data structures shown below:.

Next, we assume the first client terminates its connection. When our server reads this connected socket, read returns 0.