[e12e]

Afaik erlang has a lock as well - in fact I think most green thread implementations do: what you want/need at a minimum is one os process or thread per cpu core that works as a scheduler and then some form of (co-operative) scheduling with only user-mode/low-overhead context switching?

[brightball]

Scheduling and locking aren't the same thing. Here's a brief excerpt from Joe Armstrong that I found on SO while looking for a good explanation.

> [Erlang] is a concurrent language – by that I mean that threads are part of the programming language, they do not belong to the operating system. That's really what's wrong with programming languages like Java and C++. It's threads aren't in the programming language, threads are something in the operating system – and they inherit all the problems that they have in the operating system. One of the problems is granularity of the memory management system. The memory management in the operating system protects whole pages of memory, so the smallest size that a thread can be is the smallest size of a page. That's actually too big.

> If you add more memory to your machine – you have the same number of bits that protects the memory so the granularity of the page tables goes up – you end up using say 64kB for a process you know running in a few hundred bytes.

With Erlang, there are threads running concurrently across multiple CPU's and a preemptive scheduler within each of those threads. This is all transparent through use of Erlang processes. Essentially, many concurrent schedulers managing hundreds of thousands of processes that start out at 0.5kb each. A JVM thread is 1024kb by comparison and a goroutine is 2kb.

You're getting legitimate concurrency with Erlang, as well as isolation. There are only so many things that a single CPU can do at the same time and that's where the scheduler becomes necessary. The scheduler also ensure that if you fire off 100,000 processes and one of them is CPU intensive that it can't hog the processor and preventing the others allocated to that processor from executing.

[yellowapple]

That doesn't sound right re: Erlang; its everything-is-immutable model is supposed to avoid the need for a GIL. Erlang processes are also preemptive, so there's no possibility for a process to lock up the whole VM (unless it calls into a long-running NIF, but native code is always dangerous in a "crash BEAM if you don't get it right" kind of way).

[dragonwriter]

IIRC, Erlang uses shared mutable state internally, though its not exposed, so it needs to lock around accesses to that, but this isn't equivalent to the Python GIL.