release 0.0.0.20 and thoughts

[Billy Tanksley]

On Mon, 14 Aug 1995 spc@gate.net wrote:

> On some network somewhere in cyberspace, Billy Tanksley transmitted:

Who, me?  Oh, yes, well, I guess it was.  :)

> > On Sun, 13 Aug 1995 spc@gate.net wrote:

> > Fare' and co. appear to me to be wanting to add a third category to that: 
> > OSes that are secure because they can choose intellegently whether or not 
> > to isolate.

>   But isolation doesn't cost that much (on hardware that supports virtual
> memory) because EVERYTHING goes through virtual memory.  QNX supports
> virtual memory but doesn't swap (i.e. if you have 16M RAM in a QNX system,
> then you have 16M Virtual RAM - it doesn't swap out to disk).

Fare', this is either a question of practice or advanced theory.  I can't 
answer it, so it's up to you.  I think it's a good question.

>   It seems as if Fare and Co. believe that virtual memory is SLOW and
> EXPENSIVE and SHOULDN'T BE DONE, except in isolation boxes.  But what you
> end up with is a Mac, or Windows that doesn't swap.

>From my point of view, it is.  If you force virtual memory on everything, 
many things will have trouble.  If you only provide virtual memory as a 
service to things that need it, nothing will break.  (Simplified case.  
Murphy's law may apply otherwise in some finite states.)

> > However, there are certain things we CAN prove about that function.  We 
> > can't prove that it terminates, but we can show that it doesn't modify 
> > any permanent variables.  We can also show that it does or doesn't yield 
> > control to the multitasker.  We can show that it doesn't trash memory 
> > (aside from the recursion stack, which is contained anyways).

>   Well, because of the recursion it can't share a stack with other tasks
> (and I'm eagerly awaiting to see how tasks can share stacks).

Okay.  I'll accept that.  Do you accept my point, that what we can 
discover about this does have a certain amount of utility?

>   I can see where OO CAN deliver smaller executables, but it's far from
> being the Holy Grail of paradigms.  And as far as code reuse goes, I feel
> that shared libraries (more along the lines of DLLs or Amiga libraries
> today) offer more code reuse than OO (as done today) ever will.

Shared libraries ARE OO.  The library itself is essentially an object, 
although an immense one.  No OO operating system could be called OO 
without a thorough, powerful, dynamic linking facility.

> > Just a sec.  Sending a message outside of your thread should not block 
> > you; it probably should do a yield, but no blocking.  Now calling a 
> > method is different.

>   True.  But if a execution unit waits for a reply, it then blocks.

Of course.  That's the meaining of the word 'wait', as I understand it.  :)

> > > Preemtive multitasking doesn't prevent two execution units from cooperating. 
> > > No, really, it doesn't.  

> > As I understand it, the reverse is also true.  Coop multi does not 
> > prevent an object from preempting its own decendants.

>   Explain how that is done.

Cooperative multitasking, simply defined, is allowing tasks to return 
control on their own time rather than taking it away from them at any 
time.

If computing time is distributed to objects through some sort of tree,
with the processor being the trunk, you can easily define a 'branch' of
that tree that takes back control from all its decendants at fixed
intervals.  You cannot do the reverse, have the tree force control but 
have a branch refuse it.

> > >   Please, don't take away my freedom to do stupid things to my computer.  I
> > > thought that's what TUNES was about.  And if I want preemtive multitasking,
> > > I should be able to add it, no?  But here you are, dictating what YOU thing
> > > everybody should want.

> > No, he's dictating the basic design of TUNES, and he's trying to keep it 
> > open.  The nice thing about cooperative multitasking is that you can 
> > easily replace it with preemptive-- you can't go the other way around.

>   Well, from what I hear from the Mac people, it isn't quite as easy as you
> make it out to seem.

That's because the Mac OS wasn't designed to be flexible in that way.  
It's not even object-oriented!  TUNES is.  That's it's whole reason for 
existance (and no, I'm not even going to pretend French HERE).

>   -spc (See, the Mac STILL doesn't have preemptive multitasking)

-Billy