Re:Re: Support for native OS threads ?

["Jecel Mattos de Assumpcao Jr." <jecel@lsi.usp.br>]

On Wed, 26 Apr 95 10:03:17 METDST Reto Kramer <kramer@al.esec.ch> wrote:
> [ lots of interesting stuff deleted ]
> 
> The notion of active vs. passive objects has proved to be an advantage in
> our project because the application developers are shielded from low level
> process/semaphore/queue related synchronization issues and can work on the
> a higher abstraction level provided by asynchronous/synchronous/future and 
> balking message passing sematics.

That is what I think too. BTW, what is a "balking" message send?

> - Is there any attempt to bring the notion of active/passive objects, and
>   multiple message passing sematics into self ?

I am working on it, but I don't think it will be ready in time to be
of use to you. My ( mythical ) TinySelf interpreter has only active
objects. Every message send returns a future object immediately as
the result, while the message gets queued at the receiver for later
processing ( if it is already doing something else, each object
executes a single method at a time ). If you try to send a message
to the future object, however, you block. When the receiver finishes
executing the message and returns the real answer, the future "become:"s
that answer and unblocks any waiting objects ( threads ). In code
like "x mess1 + y mess2", mess1 will block while mess2 won't ( it
will inside the + method, of course, but that doesn't matter here ).

So messages are synchronous or asynchronous depending on how they
are used, no matter what the sender or the receiver. This might prove
to be *too* simple for serious applications, but I hope it will be
enough. Of course, the way I have described it so far this model
would make recursive methods deadlock and an object like the number
2 would be a serious bottleneck in the system. But I won't go into
these details here.

> - Is it considered to be a good idea to build these features into the language
>   or should they always be provided by an add on system (if so, things like
>   the CLOS "around/before/after" functions are useful and make the 
>   doesNotUnderstand trick obsolete in certain cases).

In some systems this might be done using some metaobject protocol, but
I feel that Self's "message passing at the bottom" approach makes it
better to have a built-in concurrency model.

Regards,
-- Jecel Mattos de Assumpcao Jr
   Laboratorio de Sistemas Integraveis - University of Sao Paulo - Brazil
   jecel@lsi.usp.br    http://www.lsi.usp.br/~jecel/jecel.html