release 0.0.0.20 and thoughts

[Billy Tanksley]

On Tue, 15 Aug 1995 spc@gate.net wrote:

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

> > >   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.)

>   Care to name what virtual memory causes troubles with?  About the only
> argument I can think of is that under certain systems, virtual memory
> comsumes space for the tranlation tables (not all system have this trouble,
> notably those where the virtual memory is handled externally to the CPU) and
> are *slightly* slower than non-virtual memory systems (I'm excluding
> swapping out to disk here in this case).

Virtual memory includes swapping to disk.  That's the meaning of 
virtual.  If you mean memory protection...

> > > > 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'll accept that.

Then it is clear that there is some benifit in proving such things about 
it, and thereby reducing the supervisory burden on the system.

Actually, the total amount of supervision is the same; the difference is 
that by proving those things about the task the system can ignore those 
aspects of the task during runtime.  You lose a constant amount of time 
at startup, you gain a linear amout of time during running.

> > > > 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.

>   Right.

> > 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.  
>   ^^^^^^^^^^

>   Thank you for defining preemptive multitasking.  So kind of you.

Sarcasm will get us nowhere.

>   Or in case you missed it, re-read your definition of cooperative
> multitasking, then re-read the underlined portion of what you wrote.

My point!  You can implement preemptive multitasking for a subset of a 
cooperative system.

> > You cannot do the reverse, have the tree force control but 
> > have a branch refuse it.

>   I think the analogy fails here.  What are you saying?

I'm saying that cooperative multitasking is more flexible than preemptive 
multitasking.  See my above statement for what coop can do, and notice 
that on the other hand, preemptive cannot ever fail to preempt or it 
completely fails.

> > > > 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).

>   What about Windows then?  Same deal.

What about it?  Windows is a nasty ugly kludge.

If Windows was well-designed we wouldn't even want to design TUNES.

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

>   -spc (And, except for NT, Windows doesn't have preemptive multitasking
> 	either ... )

What makes you think I LIKE windoze?

-Billy