Hacker News Reader

HNHacker News

Top New Best Ask Show Jobs

Comment by c-smile | Hacker News Reader

Parent Full thread

c-smile·

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...

View on HN

That'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.

Yep. 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.

Go 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.

No-gil has this plus a bigger footgun.

That 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.

I 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