Does the current image format associate active threads with processors? 
  Does the Squeak image even allow for more than one Processor?  When 
the image starts up it would need to assign each Processor in the image 
to a thread, and deal with the cases where the image has more/less 
Processor objects for the number of CPUs in the executing computer.  
This could require that threads be re-assigned to a different Processor 
than they were using before.  Or the image file could be independent of 
the number of processors, and assignment done on startup in all cases.  
Running the GC in a separate OS thread makes sense, if the 
synchronization overhead is not higher than the GC overhead.  For 
example you can not do heap copying with other threads concurrently 
accessing those objects.  It might make more sense to have all C 
threads coordinate pauses for GC so that you get GC activity 
concurrently on all processors when no "user" logic is running.  Either 
that or you would need to lock each object while it is in motion, and 
each access would need to check for the lock.  With spin locks that may 
be acceptable if you can control the collision rate.

Michael

On Jan 18, 2005, at 2:23 PM, Jon Hylands wrote:

> On Tue, 18 Jan 2005 14:10:10 -0800, Michael Latta <lattam at mac.com> 
> wrote:
>
>> On the practical side of things, since the Squeak interpreter is
>> basically one big C loop, how would we make use of concurrency?  Would
>> we have to fork() the interpreter for each processor...?
>
> I think that is more or less what Smalltalk MT does. I believe it also 
> runs
> the GC in its own OS thread.
>
> Later,
> Jon
>
> --------------------------------------------------------------
>    Jon Hylands      Jon at huv.com      http://www.huv.com/jon
>
>   Project: Micro Seeker (Micro Autonomous Underwater Vehicle)
>            http://www.huv.com
>