Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!news.swapon.de!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Marko Rauhamaa <marko@pacujo.net>
Newsgroups: comp.lang.python
Subject: Re: Benefits of asyncio
Date: Tue, 03 Jun 2014 09:36:51 +0300
Organization: A noiseless patient Spider
Lines: 45
Message-ID: <878upe8poc.fsf@elektro.pacujo.net>
References: <d1634744-39e8-4bfa-be76-1fd2292fd59f@googlegroups.com> <mailman.10573.1401739639.18130.python-list@python.org> <874n03t5t9.fsf@elektro.pacujo.net> <7x4n03dor0.fsf@ruckus.brouhaha.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: mx05.eternal-september.org; posting-host="ff5cf27ef3d5b31f034d3b72bdc27a41"; logging-data="4174"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+Oe33B7zqN28LqeBB5mDxr"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)
Cancel-Lock: sha1:Od5+YF35+WYU9URHimayAdmqEHo= sha1:0AGA3kf4w4Y3wuygE3UfMAdaV3g=
Xref: csiph.com comp.lang.python:72481

Paul Rubin <no.email@nospam.invalid>:

> Marko Rauhamaa <marko@pacujo.net> writes:
>>     - Thread programming assumes each thread is waiting for precisely
>>       one external stimulus in any given state -- in practice, each
>>       state must be prepared to handle quite a few possible stimuli.
>
> Eh?  Threads typically have their own event loop dispatching various
> kinds of stimuli.

I have yet to see that in practice. The "typical" thread works as
follows:

    while True:
        while request.incomplete():
            request.read()                 # block
        sql_stmt = request.process()
        db.act(sql_stmt)                   # block
        db.commit()                        # block
        response = request.ok_response()
        while response.incomplete():
            response.write()               # block

The places marked with the "block" comment are states with only one
valid input stimulus.

> Have threads communicate by message passing with immutable data in the
> messages, and things tend to work pretty straightforwardly.

Again, I have yet to see that in practice. It is more common, and
naturally enforced, with multiprocessing.

> Having dealt with some node.js programs and the nest of callbacks they
> morph into as the application gets more complicated, threads have
> their advantages.

If threads simplify an asynchronous application, that is generally done
by oversimplifying and reducing functionality.

Yes, a "nest of callbacks" can get messy very quickly. That is why you
need to be very explicit with your states. Your class needs to have a
state field named "state" with clearly named state values.


Marko