4 ms·

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

by thorax 17y ago

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.

stcredzero 17y ago
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.
- limmeau 17y ago
  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?
  - stcredzero 17y ago
    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.
silentbicycle 17y ago
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.

by thorax 17y ago

stcredzero 17y ago

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.

limmeau 17y ago
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?
- stcredzero 17y ago
  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.

silentbicycle 17y ago

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.