release 0.0.0.20 and thoughts

[spc@gate.net]

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

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

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

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

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

> > > >   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).
>
  What about Windows then?  Same deal.
 
> >   -spc (See, the Mac STILL doesn't have preemptive multitasking)
> 
  -spc (And, except for NT, Windows doesn't have preemptive multitasking
	either ... )