OS scheduling vs. VM scheduling

[todd]

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 
> <joachim.durchholz@REDACTED> 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
>> minutes).
>
>
> 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:
> http://www.erlang.se/publications/xjobb/0089-hedqvist.pdf
> ("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.)
>
> /Uffe