| Store | Cart

Re: [Python-Dev] Importance of "async" keyword

From: Nick Coghlan <ncog...@gmail.com>
Sat, 27 Jun 2015 03:29:20 +1000
On 27 June 2015 at 00:31, Chris Angelico <ros...@gmail.com> wrote:
> I come from a background of thinking with threads, so I'm accustomed> to doing blocking I/O and assuming/expecting that other threads will> carry on while we wait. If asynchronous I/O can be made that> convenient, it'd be awesome.

Folks, it's worth reading through both
https://glyph.twistedmatrix.com/2014/02/unyielding.html and
http://python-notes.curiousefficiency.org/en/latest/pep_ideas/async_programming.html

It *is* possible to make a language where *everything* is run as a
coroutine, and get rid of the subroutine/coroutine distinction that
way - a subroutine would *literally* be executed as a coroutine that
never waited for anything. The "doesn't suspend" case could then be
handled as an implicit optimisation, rather than as a distinct type,
and the *only* way to do IO would be asynchronously through an event
loop, rather than through blocking API calls.

But that language wouldn't be Python. Python's core execution model is
a synchronous procedural dynamically typed one, with everything beyond
that, whether object oriented programming, functional programming,
asynchronous programming, gradual typing, etc, being a way of managing
the kinds of complexity that arise when managing more state, or more
complicated algorithms, or more interactivity, or a larger development
team.

> But since it hasn't already been made that easy in every other> language, I expect there's some fundamental problem with this> approach, something that intrinsically requires every step in the> chain to know what's a (potential) block point.

As Glyph explains, implicitly switched coroutines are just shared
memory threading under another name - when any function call can cause
you to lose control of the flow of execution, you have to consider
your locking model in much the same way as you do for preemptive
threading.

For Python 2, this "lightweight threads" model is available as
https://pypi.python.org/pypi/gevent, and there also appears to have
been some good recent progress on Python 3 compatibility:
https://github.com/gevent/gevent/issues/38

Cheers,
Nick.

-- 
Nick Coghlan   |   ncog...@gmail.com   |   Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Pyth...@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/python-dev-ml%40activestate.com

Recent Messages in this Thread
Sven R. Kunze Jun 24, 2015 06:14 pm
Yury Selivanov Jun 24, 2015 08:16 pm
Sven R. Kunze Jun 24, 2015 09:21 pm
Steven DAprano Jun 25, 2015 02:16 am
Sven R. Kunze Jun 25, 2015 03:55 pm
Andrew Svetlov Jun 25, 2015 07:11 pm
Nick Coghlan Jun 26, 2015 10:46 am
Sven R. Kunze Jun 26, 2015 01:48 pm
Ethan Furman Jun 26, 2015 02:20 pm
Chris Angelico Jun 26, 2015 02:31 pm
Paul Sokolovsky Jun 26, 2015 02:51 pm
Chris Angelico Jun 26, 2015 03:10 pm
R. David Murray Jun 26, 2015 04:07 pm
Chris Angelico Jun 26, 2015 04:20 pm
Yury Selivanov Jun 26, 2015 03:48 pm
Nick Coghlan Jun 26, 2015 05:29 pm
Ron Adam Jun 26, 2015 06:06 pm
Nick Coghlan Jun 27, 2015 01:42 am
Steve Dower Jun 26, 2015 03:47 pm
Ethan Furman Jun 26, 2015 05:40 pm
Yury Selivanov Jun 26, 2015 06:30 pm
Sven R. Kunze Jun 30, 2015 07:39 pm
Greg Ewing Jul 01, 2015 10:02 pm
Sven R. Kunze Jul 02, 2015 08:55 pm
Nick Coghlan Jul 03, 2015 09:40 am
Sven R. Kunze Jul 05, 2015 09:50 pm
Chris Angelico Jul 06, 2015 12:27 am
Nick Coghlan Jul 06, 2015 01:41 am
Sven R. Kunze Jul 06, 2015 08:08 pm
Nick Coghlan Jul 07, 2015 12:40 pm
Steve Dower Jul 06, 2015 02:03 am
Steve Dower Jun 26, 2015 07:03 pm
Nick Coghlan Jun 26, 2015 05:05 pm
Greg Ewing Jun 25, 2015 10:02 pm
Nick Coghlan Jun 26, 2015 10:52 am
Steven DAprano Jun 26, 2015 02:22 am
Messages in this thread