How to write a non blocking SimpleHTTPRequestHandler ?

[Chris Angelico]

On Wed, Feb 4, 2015 at 12:45 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
>> But your comment is interesting because, as I understand it, a
>> non-blocking web server is simply a matter of setting timeouts on
>> sockets, catch the exceptions and move on.
>
> Now I think you might have some misconceptions about nonblocking
> networking I/O. Nonblocking I/O is done using asynchronous, or
> event-driven, programming. Your code reacts to external stimuli, never
> blocking, mostly just sleeping. The reactions are defined in callback
> routings, aka listeners, aka event handlers.

Not strictly true - that's just one convenient way of doing things. A
callback/event-handler structure lets you write a bunch of listeners
that coexist effortlessly, but it's not the only way to do
non-blocking I/O, and it's certainly not an intrinsic part of the
concept.

That said, though, it is a VERY convenient way to lay things out in
the code. The Pike system I offered, and most of the older
multiplexed-I/O systems I've used, did work that way. It just isn't
something that non-blocking necessarily implies.

>> I don't know why wouldn't that be possible with python stdlib ?
>
> It is possible using the low-level facilities. However, the traditional
> high-level facilities are built on multithreading, which (as a rule) is
> based on blocking I/O.

Multithreading is another way to cope with the same problem of wanting
to deal with different sockets on a single CPU, but I don't think it's
inherently a part of any of Python's own high-level facilities - not
that I can think of, at least? However, in terms of common programming
models, yes, multithreading+blocking I/O is an effective way to write
code, and will therefore be commonly used.

I wish more people had grown up on OS/2 instead of (or as well as)
Windows or Unix. Threading is not such a bugbear as a lot of people
seem to think. Yes, some platforms have traditionally had poor
implementations, and to be sure, you don't want to mix threading and
forking without a *lot* of care, but threads aren't inherently bad.
They're a useful tool in the toolbox. Sometimes non-blocking I/O is
the right thing to do; sometimes threads suit the problem better;
other times, something else again.

ChrisA