From: Bill Kelly <billk@...>
Date: 2005-04-09T06:43:48+09:00
Subject: Re: Seven new VMs, all in a row

From: "Peter Suk" <peter.kwangjun.suk@mac.com>
>
> VisualWorks gets around this and also solves problems the paradox with 
> not having "real" threads, wanting to do GC efficently, yet also 
> wanting to do synchronous calls to the OS.  The dilemma is this: You 
> want real threads so your VM can utilize synchronous calls to the OS.  
> However, this complicates GC immensely.  (ObjectStudio Smalltalk lost a 
> lot of performance because of having real threads.  When it was time to 
> GC, the main VM thread would have to raise a flag and wait for all the 
> other threads to detect it.)
> 
> VisualWorks can use real threads, but only in the case of calling out 
> to a DLL, and these contexts are exempt from GC.  This gives you the 
> ability to make synchronous calls without freezing the entire image, 
> yet also leaves your GC simple and fast.

Interesting.  I'd been looking forward to the day
that Ruby supports "real" OS threads with great
anticipation.  Sorry to hear there are such negative
performance trade-offs.

I'm unsure exactly what I'm trying to ask here... 
But - did VisualWorks come up with some convenient
way to invoke a DLL call on a separate thread?  From
the programmer's perspective, I mean.  I'm imagining
something like making a DLL call and getting some
object back representing the thread, from which a 
return value could eventually be obtained? ... Just
curious.

Most of my employer's Mac customers have dual processor
systems.  Our app is currently C++ and sufficiently
multi-threaded to keep both CPUs busy.  I've looked 
forward to someday being able to write a multi-threaded
Ruby app that, using real OS threads, ran on both CPUs.

Anyway - not trying to sound negative... Just was
interested to know there are trade-offs...


Regards,

Bill