Why do OS not support erlang's lightweight process?

[lang er]

Joe's thesis talks about what problems should be solved in programming
language , what should be in libraries, but doesn't discuss what
maybe presented in OS.(I haven't finished reading, so maybe I'm wrong)

But in erlang book page 125, he did discuss some special type of operating
system structure ( the switch server and
telephony application processes)(sadly,  no second part ). I mean not just
about processes' quantity, but about os processes involved in building
robust  application, for example  Fully isolated processes which are linked
and signal failure as you point out.

I think your 4 and 5 are special for erlang as a programming language,
other  items in your list are not so much programming language features.

BR!
James


2006/8/29, Jay Nelson <jay@REDACTED>:
>
> The strength of erlang is not just that you can make lots of little
> processes.  It is the combination of this with the following things:
>
> 1) Fully isolated processes which are linked and signal failure
> 2) Failure is a fundamental assumption at all times
> 3) A simplified message passing scheme
> 4) Non-mutable "variables"
> 5) Pattern-based functions (makes messaging much clearer and easier)
> 6) Hot code loading as a fundamental function of the language
>
> Of course, all of the above work both on the same local CPU or on remote
> processors.
>
> If you add processes to the OS without the means to code and manage
> processes clearly, you will make a bigger mess out of the existing
> programs because the languages are not inherently defined to support
> many processes.
>
> If you add 1-6 and remote processes, you are back to erlang, so why
> bother?
>
> It is difficult to extract the essence of one substance and inject it in
> another substance with the goal of improving the deficient substance.
> You end up with an incomplete artificial substitute.
>
> jay
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20060829/52a23d4c/attachment.htm>