MIME-Version: 1.0
In-Reply-To: <87iofjglbg.fsf@elektro.pacujo.net>
References: <mailman.18397.1422871634.18130.python-list@python.org> <47031e69-e94d-4257-8c7d-e7c00a543634@googlegroups.com> <874mr3ibve.fsf@elektro.pacujo.net> <c0e17d52-4978-48fd-8848-30426ea42e14@googlegroups.com> <mailman.18420.1422960897.18130.python-list@python.org> <b6cb0fcb-9934-41b6-a8f6-902d26f2588c@googlegroups.com> <mailman.18421.1422961678.18130.python-list@python.org> <87r3u7grd3.fsf@elektro.pacujo.net> <e6d081df-1db0-41a3-905c-e3c2845d5dda@googlegroups.com> <87iofjglbg.fsf@elektro.pacujo.net>
Date: Wed, 4 Feb 2015 01:03:37 +1100
Subject: Re: How to write a non blocking SimpleHTTPRequestHandler ?
From: Chris Angelico <rosuav@gmail.com>
Cc: "python-list@python.org" <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.18424.1422972220.18130.python-list@python.org>
Lines: 45
NNTP-Posting-Host: 2001:888:2000:d::a6
Path: csiph.com!usenet.pasdenom.info!bete-des-vosges.org!feed.ac-versailles.fr!nerim.net!novso.com!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Xref: csiph.com comp.lang.python:85147

On Wed, Feb 4, 2015 at 12:45 AM, Marko Rauhamaa <marko@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