Peter Suk wrote:
> 
> Why is it that you'd want real threads?  What can real threads do that 
> Ruby VM threads can't do?  The answer is synchronous calls out to OS 
> services.  (As well as utilizing multiple processors, but that's another 
> issue.)

Yes, I want synchronous I/O and true multi-cpu execution.  And if I 
can't satisfy these needs without dropping into a very different 
language, I'll be disappointed.

> In general, DLLs that you call out to are doing their own memory 
> management.  At least I hope so, or they're going to be a source of 
> memory leaks.

Sure, but I am questioning the decision to rely exclusively on external 
compiled DLLs to access real threads.  I want to write as much code as 
possible in the "primary" language, for all the obvious reasons.

> I need to get used to the idea that not every implication of everything 
> I post here is going to be fully appreciated.

We can't read your mind.  You might want to start compiling a FAQ.

> Ruby has some great 
> attributes.  But it is not the first to have these!  If you look under 
> the covers, Smalltalk and Ruby are very alike.  Startlingly alike.  Ruby 
> makes some design decisions which sacrifice performance in exchange for 
> implementation & programmer convenience.  But these differences are 
> really not that big a deal.

I appreciate the philosophical similarities, but I think you trivialize 
the impact of implementation and (especially!) programmer convenience.

> At bottom, both environments use the 
> "everything is an object" principle.  At bottom, everything is just 
> messages sent to objects.  Everything is dynamic, and there is no 
> "compile-time vs. runtime" divide.

I would be more interested in your list of things that are different, 
since that is where the real work will have to be done.

-- 
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/>