0

I'm having some trouble conceptualizing what the big deal is with greenlets. I understand how the ability to switch between running functions in the same process could open the door to a world of possibilities; but i haven't come across any examples of how they solve problems standard python techniques cannot (other than the nested-functions-in-generators problem--which, honestly..."meh").

Take this example from greenlet's main page that is basically a more complex way of doing this:

def test0():
    print 12
    print 56
    print 34

I know it's just a superfluous example, but that seems to be the long and the short of what greenlets can do. Unless you are that much of a control-freak that you have to be the one who decides when, where, and how every line of code in your application is executed, how is test0 improved by using greenlets? Or take the GUI example (which is what interested me in greenlets in the first place); It's shouldn't hard to ponder a strategy that doesn't require the while loop in process_commands, no?

I've seen some of the cool things can be done with greenlets; but only in conjunction with some other dark sorcery implemented in another package (e.g., Stackless, gevent, etc.). Even with those, the greenlets aren't sufficient, requiring them to subclass.

My question:

What are some real-world examples of how one can one use greenlets, by themselves, to enhance the functionality of python? I suspect the answer lies in networking--which would probably be why i don't understand. But are there any others?

Community
  • 1
  • 1
Noob Saibot
  • 4,573
  • 10
  • 36
  • 60
  • This isn't quite an answer, but I highly recommend checking out [this article](https://glyph.twistedmatrix.com/2014/02/unyielding.html) by the founder of Twisted. It discusses various types of concurrency, including greenlets. He ultimately argues that concurrency using libraries like greenlet are inferior to other options, but it might help explain why people do use it. – dano Jun 28 '14 at 02:03
  • Also worth looking at: This [blog post](http://emptysqua.re/blog/motor-internals-how-i-asynchronized-a-synchronous-library/) by the author of Motor, which is an asynchronous driver for MongoDB. Motor achieves its asynchronous behavior by wrapping the synchronous pymongo driver in greenlets. – dano Jun 28 '14 at 02:19

2 Answers2

0

Note that your example has explicitly woven all the prints together into one function. In a real program, you don't just have two functions; you have some arbitrary number of functions, some of them even from third-party libraries you don't control, and rewriting all that code to interleave all the statements is not quite so simple.

GUIs are actually an excellent example: by letting the event loop (which is the way you handle commands in practice, btw) suspend itself when there are no events to read, your GUI can remain interactive on the same thread. If the event loop had to actually stop and wait for the user to press a key, your GUI would freeze, because nothing would be telling the OS to redraw the window.

Not that I'm a huge fan of gevent in particular; I'm placing my bets on the stdlib asyncio library. :) But it's all the same idea really: when you have some work to do that involves a lot of waiting, let other code run in the meantime.

Eevee
  • 47,412
  • 11
  • 95
  • 127
  • So greenlets are useful in asynchronous inputs, and when you want to monkeypatch code you didn't write? That's fine; but what about other code you *did* write? From what i've been reading, many seem to be hailing greenlets (green threads) as some sort of "concurrency messiah" that's come to save us from python's GIL-Satan, and other programming demons. Are these two uses enough to warrant such a pedestal? – Noob Saibot Jun 28 '14 at 02:12
  • blocking operations are usually built on input and output primitives built into the library or framework, so interleaving isn't an option. and there's ultimately only _one_ use, but i think I/O is a common enough operation to warrant some excitement, yes. :) – Eevee Jun 28 '14 at 02:22
0

Essentially any problem where you don't want to block the rest of application while waiting for something to "come back at you" (e.g. sleep, socket). Or in other words, any problem where event-driven development would make things easier.

  • Networking as you mentioned.
  • GUI.
  • Simulations/games where you might have 1000s of Actors and you want them somewhat to act independently.
  • Gluing synchronous with asynchronous libraries/frameworks.
Pithikos
  • 18,827
  • 15
  • 113
  • 136