Why not goroutines?

716 views
Skip to first unread message

Guido van Rossum

unread,
Aug 18, 2013, 2:19:57 PM8/18/13
to Nicolas Grilly, python-tulip
On Sun, Aug 18, 2013 at 3:00 AM, Nicolas Grilly <nic...@garden-paris.com> wrote:
On Sun, Aug 18, 2013 at 2:32 AM, Guido van Rossum <gu...@python.org> wrote:

I think Go's strategy is great... for Go. It is aided by the compiler, though, and it's hard to see how the idea would carry properly to Python. If you want to voluntarily use Go's *style*, you can use the Queue class (either the threaded variety or Tulip's version). IIRC it's not possible to set the queue size to zero (passing 0 means unlimited buffer size) but we could add an UnbufferedQueue subclass for that purpose if there's demand.

Yes, Go's strategy fits very well in the overall language design. From an engineering point of view (not a stylistic point a view), what makes difficult to carry this strategy (goroutines communicating through channels with implicit context switching) properly to Python? I'm not sure to understand why the compiler makes this easier in Go.
 
PS. Next time can you start a new topic rather than reviving such an old thread?

Sorry for this. I thought it was on topic. Next time I'll start a new thread :)

I'm starting a new one now named "Why not goroutines".

To answer why it's not easy to add goroutines to Python, it would actually be very easy if you mapped them into threads. Implementing a Channel class in Python is simple enough (just modify the Queue class to avoid the buffer altogether) and then you are in business.

Of course, you have to voluntarily refrain from mutating global state (the Python runtime won't stop you from doing this) and you're using OS threads, which are much more heavy-weight than goroutines -- there's no way you could create 100,000 OS threads, like Go boasts you can do with goroutines. To address this you can use greenlets, but we already went over that in the previous thread. :-)

And without the compiler recognizing goroutines and channel operations, you still are required to remember to use the proper API voluntarily, you won't have Go's select syntax, and so on.

Basically, what you can do without help from the compiler is not very interesting. If you want a more specific answer, you'll have to propose a specific example of a program using goroutines that you find elegant, and I'd be happy to try and figure out how it could be translated into Python.

--
--Guido van Rossum (python.org/~guido

af.sta...@gmail.com

unread,
Aug 19, 2013, 1:39:12 PM8/19/13
to python...@googlegroups.com, Nicolas Grilly, gu...@python.org
Hi Guido and Folks:


On Sunday, August 18, 2013 2:19:57 PM UTC-4, Guido van Rossum wrote:


I'm starting a new one now named "Why not goroutines".

To answer why it's not easy to add goroutines to Python, it would actually be very easy if you mapped them into threads.

I just joined this group to see if it is feasible to use Tulip with Stackless Python.
 
To address this you can use greenlets, but we already went over that in the previous thread. :-)

I am new here. Which thread is this?
 
And without the compiler recognizing goroutines and channel operations, you still are required to remember to use the proper API voluntarily, you won't have Go's select syntax, and so on.

A few years ago, I wrote a Stackless Python prototype with PyPy stackless.py and greenlets that implements select (http://code.google.com/p/stacklessexamples/wiki/StacklessExamples). To implement select, I read Robert Pike's really cool paper "The Implementation of Newsqueak" and ripped off Russ Cox Plan 9 channel code. I am about to do a rewrite, in part because I don't like the API, the code is not in PEP 8 and I want to integrate join patterns (and the name select confuses folks).  Yes the API is a little unwieldily. However having select as a language feature presents its own problems. For example, what if you want to change the number of readers and senders at runtime?  Go has a function in the reflect package called Select to do this:

func Select(cases []SelectCase) (chosen int, recv Value, recvOK bool)

Basically, what you can do without help from the compiler is not very interesting. If you want a more specific answer, you'll have to propose a specific example of a program using goroutines that you find elegant, and I'd be happy to try and figure out how it could be translated into Python.

Cheers,
Andrew

af.sta...@gmail.com

unread,
Aug 19, 2013, 1:50:11 PM8/19/13
to python...@googlegroups.com, Nicolas Grilly, gu...@python.org
Hi Folks:

>To implement select, I read Robert Pike's really cool paper "The Implementation of Newsqueak" and ripped off Russ Cox Plan 9 channel code.

Oops, I forgot

1) Russ Cox pointed me to his implementation.
2) I started by writing a clean-room implementation based on the paper. 
3) My friend Kevin wrote much of the current version based on libthread/channel.c

Cheers,
Andrew

Guido van Rossum

unread,
Aug 19, 2013, 2:05:18 PM8/19/13
to af.sta...@gmail.com, python-tulip
Andrew, I'm sorry, I don't recall who you are. I don't see any questions in your post except "what thread are you referring to". It is the one with title "Why not coroutines", (only one character different from this one :-). You can find it in the Google group archives.
--
--Guido van Rossum (python.org/~guido)

Andrew Frances

unread,
Aug 19, 2013, 2:16:17 PM8/19/13
to gu...@python.org, python-tulip
Hello Guido and folks:

> I don't see any questions in your post except "what thread are you referring to". It is the one with title "Why not coroutines", (only one >character different from this one :-). You can find it in the Google group archives.

Thanks for the information. However if you more carefully read my original post, I presented a reason based on experience for why you would want something like Select as an API rather than a language feature. 

--Andrew

Reply all
Reply to author
Forward
0 new messages