Kill GIL

[Dave Brueck]

Donn Cave wrote:
> Quoth Dave Brueck <dave at pythonapocrypha.com>:
> ...
> | Another related benefit is that a lot of application state is implicitly and 
> | automatically managed by your local variables when the task is running in a 
> | separate thread, whereas other approaches often end up forcing you to think in
> | terms of a state machine when you don't really care* and as a by-product you 
> | have to [semi-]manually track the state and state transitions - for some 
> | problems this is fine, for others it's downright tedious.
> 
> I don't know if the current Stackless implementation has regained any
> of this ground, but at least of historical interest here, the old one's
> ability to interrupt, store and resume a computation could be used to
> 
> As you may know, it used to be, in Stackless Python, that you could have
> both.  Your function would suspend itself, the select loop would resume it,
> for something like serialized threads.  (The newer version of Stackless
> lost this continuation feature, but for all I know there may be new
> features that regain some of that ground.)

Yep, I follow Stackless development for this very reason. Last I heard, a more 
automatic scheduler was in the works, without which in can be a little confusing 
about when non-I/O tasks should get resumed (and by who), but it's not 
insurmountable. Ideally with Stackless you'd avoid OS threads altogether since 
the interpreter takes a performance hit with them, but this can be tough if 
you're e.g. also talking to a database via a blocking API.

> I put that together with real OS threads once, where the I/O loop was a
> message queue instead of select.  A message queueing multi-threaded
> architecture can end up just as much a state transition game.  

Definitely, but for many cases it does not - having each thread represent a 
distinct "worker" that pops some item of work off one queue, processes it, and 
puts it on another queue can really simplify things. Often this maps to 
real-world objects quite well, additional steps can be inserted or removed 
easily (and dynamically), and each worker can be developed, tested, and debugged 
independently.

> I like threads when they're used in this way, as application components
> that manage some device-like thing like a socket or a graphic user interface
> window, interacting through messages.  Even then, though, there tend to
> be a lot of undefined behaviors in events like termination of the main
> thread, receipt of signals, etc.

That's how I tend to like using threads too. In practice I haven't found the 
undefined behaviors to be too much trouble though, e.g. deciding on common 
shutdown semantics for all child threads and making them daemon threads pretty 
much takes care of both expected and unexpected shutdown of the main thread.

Usings threads and signals can be confusing and troublesome, but often in cases 
where I would use them I end up wanting a richer interface anyway so something 
besides signals is a better fit.

-Dave