3 ms·
Keep GIL but introduce Workers a la JS [0] ? Worker [thread] is a sandboxed VM [context] with its own GIL. Communication between these is done through messagi
by c-smile 3y ago
Keep GIL but introduce Workers a la JS [0] ?
Worker [thread] is a sandboxed VM [context] with its own GIL.
Communication between these is done through messaging so no sync primitives are required.
Go's routines have similar concept.
I think that if it OK for Go it should be OK for Python, no?
[0] https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...
- dragonwriter 3y agoThat's subinterpreters in a single process, and the Python runtime already has that (though the only API is from C, not Python, currently); Python API is planned for 3.13.
- fulafel 3y agoYep. The traditional sub-interpreters system in Python still used the single shared GIL so it wasn't a solution for parallelism. But just recently the "per-interpreter GIL" was implemented, it shipped in Python 3.12.
- ksec 3y agoSounds like Ruby's Ractor.
- thibaut_barrere 3y agoExactly!
- akdor1154 3y agoGo also has very easy data races when accessing the same data from different goroutines, I'm not sure Python would accept such a well-cocked footgun.
- tgv 3y agoNo-gil has this plus a bigger footgun.
- _ZeD_ 3y agothat's... awful
- johncolanduoni 3y agoThat doesn't get you much more than Python's multiprocessing; you still need to have any state shared between the processors in a simple linear memory and not in Python objects if you follow the web's model of postMessage + SharedArrayBuffer.
- spacechild1 3y agoI see at least 3 advantages: 1. Threads are significantly cheaper than processes in terms of memory, setup and context switch overhead 2. Inter-thread-communication is simpler and more performant than inter-process-communication 3. C extensions can share data structures across (sub)interpreters
- deleted 3y ago[deleted]