Peter Suk wrote:
> On Apr 8, 2005, at 3:04 PM, Glenn Parker wrote:
> 
>> Peter Suk wrote:
>>
>>> VisualWorks can use real threads, but only in the case of calling out 
>>> to a DLL, and these contexts are exempt from GC.
>>
>> Well, that's a major hole, isn't it?
> 
> There is clearly some kind of disconnect here.  Are you expecting that 
> the DLL be subject to Ruby GC & memory management?  Are you saying it's 
> some kind of "hole" that the context which is doing the call-out is not 
> being GC'd for the duration of the call?

Perhaps there is a disconnect, but I didn't think I was that obtuse.

You said VW can use real threads, but only in the case of calling out to 
a DLL, and no GC.  To me, that strongly suggests that the code executing 
in the real threads uses some traditional compiled language with manual 
memory management, e.g. C.  If that is the price for getting real 
threads, it's not very attractive to me.  If I have misunderstood, then 
please explain further.

>> And I suspect today's Ruby has pretty much the same "feature" as 
>> VisualWorks in this regard, that is to say I could create a Ruby DLL 
>> that spawned real threads and let them do their own memory management.
> 
> Please re-read my message.  Your response doesn't make any sense at all, 
> especially with the 2nd sentence -- unless I am missing out on something.

Well, maybe you're missing something, or maybe I need more help 
understanding the VW technology.  I've read all your messages and I 
think I understand the general proposal, which is quite intriguing, or I 
wouldn't waste my time on it.

> And please, stop this stupid "our X is better than yours" nonsense.  
> Such pride is misplaced on a particular VM/Language/paradigm.  I am here 
> to share what the Smalltalk world has been acruing for some time, and am 
> prepared to go through a lot of effort to do it.

Let's get one thing clear, I don't give a fig for language wars. 
Smalltalk has obviously solved a lot of problems that Ruby still 
struggles with, but it hasn't necessarily solved them in the way that 
makes sense for Ruby.  So, please pardon me if I "look a gift horse in 
the mouth".  Your willingness to invest your time and skills is 
noteworthy, but it doesn't mean that a Smalltalk VM is the ultimate 
answer for Ruby.  Goodness knows, I'd love to see you deliver on the 
promise of your proposal, because I think Ruby needs a radical 
performance upgrade.

I don't know if I can convince you of this, but I'm trying to ask some 
sincere and probing questions about your proposal.  This kind of probing 
is exactly what you invited by announcing your plans here.  Why act so 
surprised when you get a bunch of naive Smalltalk questions from a group 
of Ruby folk, anyway?

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