Conversation

Blaming the lack of true multithreading in several languages on a "GIL" is a classic case of missing the forest for the trees. It's not an implementation detail—it's a case of thread safety being very hard to compatibly graft onto an ecosystem that was never designed for it.

123

Patrick Walton

@pcwalton

May 3, 2021

If your language ecosystem is entirely single-threaded, you actually *want* a GIL. Why would you give up single-threaded performance for theoretical multithreaded benefits if multithreading doesn't actually work?

Replying to

Better would be not supporting threads and therefore not needing locking at all. Explicitly build around using multi-processing instead of multi-threading. nginx takes this approach for their workers to avoid the overhead of thread safety in their allocators and other APIs.

Replying to

and

They only use threads to implement thread pools for AIO on Linux. Those threads need to work around not being able to use the normal APIs. They have a module ecosystem including Lua and JS support where these benefits and constraints also apply. It's a big win for them overall.

9:49 PM · May 3, 2021Twitter Web App