Class -> Object -> Thread

[Gary D. Duzan]

In Message <9304020340.970@mulga.cs.mu.OZ.AU> ,
   Michael David WINIKOFF <winikoff@mulga.cs.mu.oz.au> wrote:

=>> [ Thus spake Gary D. Duzan ]
=>> 
=>>    How's this sound for a small idea? A chunk of code is a class,
=>> with no external interface except an initialization entry point.
=>> When an external entity initializes the class, it acquires passive
=>> state and sets up its interface, but is not (necessarily) active
=>> afterwards. When a method call is made, either internal or external
=>> to the object, the active method becomes a thread, including active
=>> state (registers, stack, etc).
=>
=>I don't understand what you're suggesting.

   That's ok, I'm not certain I do either. :-) I was just trying to
come up with a basic idea of how code, state, and execution can be
modeled in the system. In this model, for example, compiling and
linking would be seen as class generation, starting a server or other
process (where the initialization code may start a concurrent method
call to allow the object to remain active) would be seen as object
creation/initialization, and IPC/method calls (same thing) would be
seen as starting a thread in the object. If the calling thread is
blocked, then you can view this as the thread continuing in the other
object.
   My mention of IPC brings to mind the question of what to consider
a process. Historically, a process includes both active and passive
state, in a one-to-one relationship. My object model has no active
state itself, while several active states (threads) may operate
concurrently on the passive state. Thus, I would suggest that my
model would be better off if we don't try to force the notion of a
process onto it.

=>Agree!
=>Yes!
=>Yes!
=>Yes!
=>Yes!

   So do you agree with me, or what? :-)

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts