At 15:21 +0530 12/19/02, Aravind Srivaths wrote:
Is that statement true for _all_ systems on which Perl runs. And especially if you're using multiple CPU's ? It was my impression that the fact that there are systems in which the threads do _not_ necessarily share the data space, which may make your scheme not generally applicable. And I guess no one is waiting to maintain two different ways of doing threads and shared variables.It should be possible for multiple interpreters to hold a reference to the same variable (contrary to what Elizabeth says) - after all the variable just resides in a heap and all threads share the data space.
But please, do not expect me to be the know-it-all on the threads internals. I have been a very heavy threads user in the past 6 months, that's all. I just started on Cozens & Jennings. All current threads users would welcome any effort to get threads working better, so if you think you have a better solution that will work, more power to you!
You may have located the "memory leak" with shift on shared arrays here... I guess the phrase "Patches welcome" applies here... ;-)How is a shared variable associated with the shared context?And should a shift on a shared array not return a mortal variable - it seems to me that it allocates a new sv and returns that in Perl_sharedsv_associate: /* Now if requested allocate private SV */ if (psv && !sv) { printf("created new sv\n"); *psv = sv = newSV(0); }
Liz
