stephane ducasse wrote:
> you can have a look at Actalk (the 1989 paper of JP briot) in a few
> lines of code you get message put in queue and each object having its
> own thread.
> I can send you the paper. There is also an implementation maintained
> by serge stinckwich may be of the 1996 paper.
>
> Stef
Stef,

What few lines of code?  And can this be done to selected objects, so as
to permit sensible factorization of object systems into threads?

I've asked this same question before: http://wiki.squeak.org/squeak/552

In all seriousness, I still believe that a clean breakthrough would be a
vital long term enabling devolopment for Croquet in particular, and Squeak
generally.

Is this paper online (or can it be scanned and legally posted online?

    Thanks,

        Ed Boyce

>
> On 7 janv. 07, at 19:14, Zulq Alam wrote:
>
>> J J wrote:
>>> I have read an article recently on transactional memory [1] and it
>>> seemed to me like this might be a great opportunity for
>>> smalltalk.  If a VM was created for squeak that did native threads
>>> with transactional memory then I think it might be possible that
>>> most (if not all) the code we have in the image right now could
>>> work about the same (and my belief comes from the fact that if we
>>> introduce real threading then any state changing operation is
>>> going to have to be "atomic", so we wouldn't use the keyword as
>>> much as they do).
>>
>> I don't understand what you mean by 'any state changing operation
>> is going to have to be "atomic", so we wouldn't use the keyword as
>> much as they do'? We would have to use the atomic keyword wherever
>> there is a state change - why is this less for Smalltalk?
>>
>> I found http://wiki.squeak.org/squeak/537 very interesting on this
>> whole subject. I was especially interested in the work on Merlin/
>> TinySelf where message sending is (as I understand it)
>> asynchronous. I wonder what would be required to spike this in
>> Squeak even if just simulated?
>>
>> Thanks,
>> Zulq.
>>
>>
>>
>>
>
>