Kernel 0.11, [arf1]
Michael David WINIKOFF
Fri, 26 Mar 93 16:42:05 EST
> Howdy all!
> Some comments on the kernel so far - looks pretty good!
> One statement concerns me: "every object is a process..." I'm assuming you
> mean every *instance* of an object is a process, which would require a lot of
> overhead. (As an estimate, a system might use between 256 bytes and 8k to
> represent a single process and its registers, state of the machine, etc.)
Let me explain.
What I meant was that a MOOSE object is defined to be a process.
A small object that isn't a process (Eg. is internal to a process/large-object)
isn't viewed as an object by the system.
Ie. objects REPLACE processes -- there is only the single (merged) concept.
[Private objects deleted]
Private objects are not viewed as MOOSE objects.
> Now take a look at a database application: multiple processes would need
> access to the same instance of an object (a record in the database) at once.
> Each process can change the object, and (possibly) one process changing a
> database record notifies all other processes with interests in that record
> that a change has been made so they may update themselves accordingly. This
> type of object is a 'public' object, stored (most likely) in some shared memory
> space, and has some special characteristics allowing it to be shared between
> processes and (in a distributed system) between systems. Methods for sharing
> these objects between processes and systems are implemented in the next type
> of object, which is....
> The process object. Descendants of this type of object would be applications,
> device drivers, and *possibly* the kernel itself. Processes have some way of
> making themselves available to other processes, and if one process knows the
> interface to another, they can communicate directly. As mentioned before,
> shared object stored in this manner would probably be distributed through this
> So far, this is our object heirarchy:
> | |
> shared object process object
> An 'object' is the definition of how an object in this system is structured,
> how it behaves, how its attributes (data) are stored, and how its methods
I don't think we should dictate how the data is stored -- we shoudl instead
limit ourselves to accessing said data through methods. Comments?
> (functions) are accessed. Most languages (C++) do not define an 'object'
> object, but in this system *all* objects have a common ancestor. If, for
> example, an object were defined in C++ with no ancestors, it would (by the
> compiler) be given the 'object' ancestor by default. This ties all objects
> together with a single ancestor, closing a major gap in to OOP paradigm.
> Maybe it defines some methods...I don't know yet. This kind of object is
> created in a private memory area, which must be owned by some process.
> Maybe this object defines some virtual methods for loading itself and storing
> itself to and from a 'file' object? This way, all objects are given the
> interface to load/store, and whether or not this is implemented is up to the
> object designer. Also, the 'object' object would be given some method to
> identify itself in a system dependent manner, defining which module the object
> is found in an what the object is called. (module:object) This I don't know
> how to define yet...
> A 'shared object' is the next step in this heirarchy, and represents an object
> which can be shared between mutlitple processes, or (eventually) between
> systems in a distributed system. This object must be able to handle itself
> contention of multiple processes through the use of semaphores or other similar
> devices. This kind of object is created in a shared memory area, which must
> be owned by some process. Some process must manage these - they are not
> independent in and of themselves.
> A 'process object' is the type of object associated with a task or application.
> When a process object is instanciated, it can be made public to other proceses
> (or not) through which other processes have access to its methods. These are
> managed by the kernel, and access to processes (finding a process object
> pointer?) is done via the kernel.
> An example using this scheme, implementing a database application:
> The database process is started for a particular database, placing it in the
> system wide table of processes, or giving only a limited subset of processes
> access to it. (This access and protection still needs to be ironed out...)
> Another process begins, and needs to access the database. It requests the
> kernel for a pointer to the database process object. Next, it needs to find
> all records in the database with a certain search criteria, and uses the
> database process object's methods to perform this search, returning a list of
> objects. Each of these objects are instances of shared objects stored in
> memory managed by the database process; for all the requesting process knows,
> it instanciated these objects itself and should treat them as such. *Note*:
> directly modifying the contents of these objects is not allowed... Next,
> another process accesses the database and also requests similar records, so
> now two processes have pointers to identical objects (the same data, *not*
> two instances!). The first process *destroys* its version of the shared
> objects (the database records) when it is through, just as it would with any
> other object, except instead of freeing memory it only dereferences the object,
> and when the reference count reaches zero the object is actually destroyed.
> Did I mention the second process existed on another system? :-)
> Basically, when processes are created some access protection is set to allow
> use by a single user, multiple users, multiple systems, etc. This example
> database application would probably allow multiple user access, but only a
> limited subset of "installed" users. I.E., the database has complete control
> over which users are allowed to access its process (via the kernel) to begin
> I envision shared memory being read-only by all processes except the owner.
> (The owner can write as well.) Across distributed systems, process should not
> even be allowed to read shared memory. This way, all information can be
> gathered from an object without a task switch; to modify an object requires a
> task switch to the owner's task, so each method in a shared object must be
> classified in some way to allow this to happen.
> Ok...these thoughts are a little sketchy, but coming together nicely. Let me
> know what you think! This is absolutely implementable - I've done my research
> there. I think this is our best bet of an object oriented system...
Computer science honours. University of Melbourne, Australia.