Hacker News Reader

Comment by ghshephard | Hacker News Reader

My favorite line (buried a few hundred lines deep) --IN 2009 Q3 and Beyond:

"In addition, we intend to remove the GIL and fix the state of multithreading in Python."

The GIL has really frustrated me for multiple years. When you're embedding Python into an application, it's really difficult to take advantage of the best multi-core options Python has because those options are all multi-process tricks.

At Pycon last year, when I reminded Guido about the difficulty for embedded apps (that can't fork 200MB processes every time a thread is needed), he shrugged and recommended Jython or IronPython usage.

It's great to see that we'll have this problem solved in a few years. (I assume it will take that long to be production-worthy.)

I'm sure this LLVM integration and change will pretty much break/invalidate all of the embedding API, but to me it'd be worth the rewrite.

I'd like to see an optimization involving threads and GC. Some Smalltalk VMs only spawn real threads when there is a system call involved. However, the stack frames involved in the calls are momentarily exempt from GC. This means that the GC never has to wait for threads to synchronize to proceed with operations. But the language gets all of the benefits of real threads.

I don't understand the "stack frames are exempt from GC" thing -- do you mean the stack frames do not contribute reachability roots to the garbage collection or that the stack frames themselves are not garbage-collected?

Nothing directly involved in the call participates in GC. In VisualWorks Smalltalk, these calls are special. (These are only calls out through the DLLCC facility. I believe they are marked by pragmas.) They might contribute reachability roots, though that might be problematic. I seem to remember that objects created in that stack frame are not garbage collected. Since these methods are marked, the compiler can treat these calls specially. I'm pretty sure that the objects are spawned in a different space. I think this would mean that those stack frames can't mutate objects created before the call. (This would make these calls functional in flavor.) They should be able to refer to such objects, as this will only cause an exception if things go wrong.

The only thing that happens in these methods in VisualWorks Smalltalk is marshalling to call out to DLLs implemented in C.

Have you looked at Lua? It's pretty similar to Python (with a bit more Scheme influence), but is very deliberately designed for embedding. Also, all state is contained in the Lua_state pointer, so you can concurrently run several Lua VMs when it suits you to. You don't need to wait years for Python to work its concurrency issues out.

Tbh what is really needed is optimized message passing ala the actor model. It is a leap forward and avoids a lot of problems that threads face (subtle concurrency bugs).

You mean CSP-style, like Alef and Limbo from Bell Labs? Have you come across PyCSP? It has multiple backends, including greenlets which are nice and lightweight. http://code.google.com/p/pycsp/

Stackless is inspired in that paradigm too.

Yes it does avoid many problems, but it's unsuitable for other important scenarios. We need both. Message passing should be a design choice, not an excuse for a limitation in some language runtime.

That's interesting, which scenarios do you consider it unsuitable for?

The scenario I deal with most of the time is a large, read-mostly, in memory custom data structure that is accessed by multiple clients. More and more data fits into memory nowadays so that's going to be a very common scenario for many data analysis tasks in the future.

Reply on news.ycombinator.com