At 9:49 AM +0100 12/23/03, Elizabeth Mattijsen wrote:
At 14:16 -0500 12/22/03, Dan Sugalski wrote:
At 8:05 PM +0100 12/22/03, Elizabeth Mattijsen wrote:
In Perl 5, the sharedness of a variable can be determined at run-time. Leo's mentioned that a PMC will never change its address during its lifetime. Can these two requirements be met if there are threaded and unthreaded versions of PMC vtables?
Yes. Making a PMC shared can be as simple as swapping out the vtable pointer in the PMC structure--no need to move it around at all. (Or, worst case, turning the PMC into a reference PMC for the actual PMC, whose contents get moved to a new header, which is legal-ish)

It's that last thing I'm worried about. That all thread related things in Parrot are forced to use an extra indirection and consequent performance penalty.

They'll live. Python and Ruby both have a single global interpreter lock and nobody much cares.


People won't move to parrot because of signal or thread support, or because we give them a cookie. People will move to parrot because it runs perl 6, or because it gives them cross-language support for perl, python, and ruby, or because it's an easy target to write a custom language for.

Threads are useful, they're important, and they will be supported properly. All indications are, however, that most programs will be non-threaded, and decisions about the design are made with that in mind.
--
Dan


--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
[EMAIL PROTECTED]                         have teddy bears and even
                                      teddy bears get drunk

Reply via email to