----- Original Message ----- 
From: "Igor Stasenko" <siguctua at gmail.com>
To: "The general-purpose Squeak developers list" 
<squeak-dev at lists.squeakfoundation.org>
Sent: Monday, October 29, 2007 5:59 PM
Subject: Re: Concurrent Futures


> On 30/10/2007, Rob Withers <reefedjib at yahoo.com> wrote:

>> I'd like to hear some description if the concept you have in mind, if you
>> have the time.  What are you thinking about in this arena?
>>
> Well, in my concept i don't have a vats. A computing resources(native
> threads) managed by VM and not visible at language level. So, a VM
> parallelism is not a language parallelism.
> You can't predict what native thread will serve concrete message for
> concrete object, thus a load is distributed evenly.
> This haves own limitations, but mostly when you interacting with
> external libraries through primitives - some of the libraries can not
> work (or can work differently) when you accessing them from different
> native threads.
> Some of the libraries designed with no multithreading in mind, so
> using them concurrently may cause a system crash.
> But i don't think that i'm alone with this problem. We need to find
> some good ways how to control that all calls to some external library
> must be invoked only from a single thread of execution, while for
> other libraries its ok to call them from anywhere.

How do you protect against simultaneous accesses to memory for writes/reads?

I agree that thread-safing the primitives is a key task.

Cheers,
Rob