OS scheduling vs. VM scheduling
Thu Jan 22 16:08:47 CET 2004
There is also a cultural issue thay may come up with threads
is that many if not most programmers are conditioned against threads.
Any design that uses a lot of threads meets with resistence,
even in real-time systems like vxworks which have excellent
scheduling latencies and can handle many threads.
I have run into this over and over. If your linux box suddenly had
100,000 threads a lot of people would freak. Hiding them
in erlang processes is a quieter approach :-)
Plus, i would test the hell out if it before i believed them...
Ulf Wiger wrote:
> On Thu, 22 Jan 2004 14:49:01 +0100, Joachim Durchholz
> <> wrote:
>> Hi all,
>> When leafing through old messages, I hit on Vance Shipley's old "One
>> Million Processes" thread, and my mind made a connection to a recent
>> information snippet.
>> The new Linux 2.6 kernels have been reported to spawn processes at a
>> rate of 100.000 within a relatively short time (seconds or very few
> Yes, I remember that too.
> Note that they're talking about threads, i.e. just creating
> a context in shared memory. Erlang "threads" do not share
> memory (conceptually, even if they do in reality). This is
> something to think about if one wants to share the memory
> space with other languages -- Erlang processes _behave_ as if
> their memory is protected and separate from others.
> Another implication is that the VM has to be made thread-safe.
> It is not so today. The upside is that it would become possible
> to take advantage of multipro architectures in a wholly different
> way than today.
> The issues are well covered in the following document:
> ("A Parallel and Multi-threaded Erlang Implementation" by
> Pekka Hedqvist)
> The details that appear to have changed since then are the
> number of threads that can be created and the cost of creating
> them (but basically only on Linux.)
More information about the erlang-questions