----- Original Message ----- From: "Igor Stasenko" siguctua@gmail.com To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Monday, October 29, 2007 5:59 PM Subject: Re: Concurrent Futures
On 30/10/2007, Rob Withers reefedjib@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