Processes and Communication (2)

[Michael David WINIKOFF]

> Why remote or whatever ? That's Microsoft-like name for things: they give
> technical names to impress common users, and to show beginner programmers
> that a technique much spoken about (because too longly and unjustly left
> in the company's previous software) has (at last) been used.

A little unfortunate, however it's a standard name so people kow what you;re
talkin g about.

> 
> >> An invoced method is called a 'thread'.
> I think `invoked' should be righter.

I think `righter' should be `more correct' :-)

> Hey ! You're interfering with implementation. From external view, the object

Some issues are sufficiently important that you can't abstract 'em.
Each process having it's own address space is possible on all MMU equiped
systems.

I am still opposed to having the system based around an interpreter.
Sure, it simplifies the solutions to some problems however the efficiency 
cost is prohibitive.

> must cope with its methods. From high level, there are private members
> (code or data), but even addressing space should be (IMHO) low-level enough
> to be implementation dependant: we must also know that most processors
> don't have the same protection scheme as the 386, when they have; so we
> should rely on LLL interpreting and compiling to enforce non-interfering
> between objects. That means LLL should be `high-level' enough to know
> bounded arrays (not like C arrays).
> 
> >> kernel is reponsible for scheduling objects and providing resources as
> >> needed. Each object has a specific protection level which determines
> >> how the object's threads may directly modify the system hardware.
> To me, the Kernel should only connect objects to resources; the resource
> managers provide what they have how they will. Object threads should NOT
> modify the hardware anyhow; device drivers are there for that; object
> threads should handle neither less nor more than their `local' own members.

Hey -- we're allowing device drivers to be objects -- that should be a  
plus :-)


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.