Foundations of Python Network Programming 978-1-4302-3004-5

CHAPTER 7 ■ SERVER ARCHITECTURE
poll() because it produces much cleaner code, but many people choose select() because it is
supported on Windows.
As servers today are being asked to support greater and greater numbers of clients, some people
have abandoned both select() and poll() and have opted for the epoll() mechanism provided by
Linux or the kqueue() call under BSD. Some programmers have made this switch with solid numbers to
back them up; other developers seem to switch simply because the latter calls are newer, but never
actually check whether they will improve performance in their specific case.
Which mechanism should you use in your own code?
My advice is actually to avoid both of them! In my opinion, unless you have very specialized needs,
you are not using your time well if you are sitting down and writing anything that looks like Listing 7–7. It
is very difficult to get such code right—you will note that I myself did not include any real error handling,
because otherwise the code would have become well-nigh unreadable, and the point of the listing is just
to introduce the concept.
Instead of sitting down with W. Richard Stevens’s Advanced Programming in the UNIX Environment
and the manual pages for your operating system and trying to puzzle out exactly how to use select() or
poll() with correct attention to all of the edge cases on your particular platform, you should be using an
event-driven framework that does the work for you.
But we will look at frameworks in a moment; first, we need to get some terminology straight.
The Semantics of Non-blocking
I should add a quick note about how recv() and send() behave in non-blocking mode, when you have
called setblocking(False) on their socket. A poll() loop like the one just shown means that we never
wind up calling either of these functions when they cannot accept or provide data. But what if we find
ourselves in a situation where we want to call either function in non-blocking mode and do not yet know
whether the socket is ready?
For the recv() call, these are the rules:
• If data is ready, it is returned.
• If no data has arrived, socket.error is raised.
• If the connection has closed, '' is returned.
This behavior might surprise you: a closed connection returns a value, but a still-open connection
raises an exception. The logic behind this behavior is that the first and last possibilities are both possible
in blocking mode as well: either you get data back, or finally the connection closes and you get back an
empty string. So to communicate the extra, third possibility that can happen in non-blocking mode—
that the connection is still open but no data is ready yet—an exception is used.
The behavior of non-blocking send() is similar:
• Some data is sent, and its length is returned.
• The socket buffers are full, so socket.error is raised.
• If the connection is closed, socket.error is also raised.
This last possibility may introduce a corner case that Listing 7–7 does not attempt to detect: that
poll() could say that a socket is ready for sending, but a FIN packet from the client could arrive right
after the server is released from its poll() but before it can start up its send() call.
113