HLL Process Model

[Francois-Rene Rideau]

Jecel said:
> On Mon, 6 Mar 1995 22:06:09 -0800 (PST) Chris Harris wrote:
>> As development seems to be progressing on the HLL front, I thought I'd
>> again re-interate some suggestions on the process model, and throw out
>> a few new things too.
>
> I think the two thing are linked, but most people would disagree.
   Not me, at least.
(When I don't answer, it means I agree. See how I don't answer to most of
this message; you see that even when I answer, I may agree too).



>> In my view of things, code should have some way of being represented, so
>> that it is easy to distinguish code that must be executed linearly from
>> that which can be executed in parallel.  (No judgements at this level
>> would be made about what SHOULD be done in parallel.)
> 
> You might do it this way. An alternative is to have the compiler look
> at the data flow and figure this out for you. Much harder, but easier
> for the programmer.
   My idea is to build automatic translation software. Beginners would
use it completely automatically, but experienced users may tune translation,
manually modify it, etc.


> Maybe Occam should be added to the list of languages to study.
   I just added it. But there already are lots of languages to review.
Yow. There's a lot of work. Perhaps you could send me your reviewing ;) ?


>> If we support changing of a process' code on the fly, we can then view
>> the OS as one huge process, composed of manys smaller things....
> 
> That is one way of looking at it. You will have to decide if your
> "prcesses" can share memory or not. That is a major question.
I say no ! What's shared memory ? Just a shared array. It has just no
useful semantic meaning. It's just an implementation trick that
brings only more overhead without factoring the concept anyway.


>> The main conceptual problem I have with this model is how to apply
>> quotas and such, when process are constantly growing, shrinking and
>> migrating.  I guess how many processes a user is running now could be
>> a factor in determining which sub-process to spawn as a seperate process.
> 
> My current idea is to give users "accounts" with a certain credit flow.
> You can spawn more processes, but they will share the same account and
> won't be able to hog all of the CPUs in the system.
   To me, the system shall not provide any finite system of resources.
There should be a generic way to multiplex and share resources. Users may
then be able to multiplex and share their own share, etc, recursively,
indefinitely. Else, there will always be problems, because if you can't
multiplex, it means you've got a security hole. This is why POSIX is bullshix:
no generic multiplexing, only specific, finite one.


> There is a missing element here - cell sharing. Can you use a cell
> as a sub-cell of two different higher level cells? If you can, you
> will have to find a way to deal with multiple "instances" of a cell.
   Yes we should be able to share objects. That's one of the basic concepts
in publishing. We sure shall allow users to publish things, shouldn't we ?
   Now, perhaps you are suggesting that linear programming (not sharing
anything) is an efficient way to implement programs. Then, I'll say that
high-level objects should be shared, whereas the system may compile them
into linear programming if it can, when it does compile...


>> I'm not sure if the overhead involved in this would be really gross,
>> or if it would be barable.  Actually, that might also be a problem
>> with my first model too, depending on how it was implimented.  Any
>> ideas?
> 
> Try writing the above example with cells. If you can't do it, you'll
> know you are in trouble ;-) If you can do it, try doing this with
> cells:
>            fact (n) = n < 2 ? 1 : n * fact ( n - 1 )
   Well, that's just about the same. Cells is an implementational
problem. If your previous function is isolated, it will be implemented
as a loop, and if n is large enough, it will be distributed to benefit
from the associativity of multiplication. So keep it high-level.
When it is actually called, the size of the argument is looked up. If it's
small enough, just loop. If large, evaluate if distribution is not better.
If you're going to call it many times, have a lookup table for values;
etc.


>> So now that we've taken that conceptual leap, why not take it a step
>> further, and have resizable, self-enclosing objects, and view the OS
>> as one huge object, composed of many sub-objects?  Sure, there are
>> logical 1st order objects, but the actual physical storage should change 
>> on the fly, so that every object, be it 40 gigs or 20 bytes, should be able
>> to best utilize mass-storage resources.
> 
> If you do object composition by "enclosing", how do you share things?
> Or am I missing something here?
   I'm not sure what you (Jecel) mean...
What's the problem with sharing particularly denoted to what Chris is saying ?
Sure, sharing is a problem, but I think it's orthogonal to what Chris was
saying.


>> Maybe there would be some way to combine processes and objects into
>> one concept, as they have sort of done is BETA.  That'd certainly be
>> neat, but the two are probably seperate enough that it might not be
>> worthwhile.
> 
> I have done so in Merlin: one object = one process ( except when
> they are not :-). This model is close to the real world where each
> component works in parallel with all of the rest. I have to allow
> some exceptions for performance ( immutable objects can have many
> processes ) and for compatibility with sequential code ( recursion
> would always deadlock otherwise ).
   Recursion would not deadlock if you distinguish internal message send
and external message send, the first one having priority. The functional
and continuation passing view also clarifies many things as compared to
the fashionable OO view that gets confused about object identity: you're
not sending the message to the *same* object, but to another one, as you
must take the state into account as for object identity...