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/>