Elizabeth Mattijsen <[EMAIL PROTECTED]> writes:
>At 10:45 AM 8/12/02 +0100, Nick Ing-Simmons wrote:
>> >Maybe it is from a CPU point of view, but it definitely isn't from a memory
>> >point of view. Because now in an array each element will need to be tied
>> >to the shared magic.
>>It isn't quite that bad. When you do a FETCH the returned value gets
>>tie - it should be freed when all references to the FETCHed value
>>go out of scope.
>
>I'm not sure I'm following you here... Could you elaborate?
tie @tied_array; # 10000 elements say
foreach my $value (@tied_array) # 10000 extra SVs tied to elements
{
print $value;
} # all freed here
foreach my $i (0..$#tied_array)
{
my $value = $tied_array[$i]; # Just one extra SV tied to an element
print $value;
} # free'd / reused here
>> >Apart from the huge memory leak that makes it impossible to use shared
>> >arrays and hashes in a production environment.
>>So let us find it.
>
>As far as I can tell, it doesn't happen when you're just FETCHing and
>STOREing in arrays or hashes, but it happens if you add or remove elements
>(such as in shift, unshift, push and pop, and adding or delete()ing keys
>from hashes), e.g.
>
> $ perl -Mthreads -Mthreads::shared -e 'my @array : shared; while (1) {
>push( @array,1 ); pop( @array ) }'
>
>will start eating away at your memory quite rigorously... ;-)
That will be a huge help in track it down.
>
>I'm not 100% sure with hashes, that may need involvement of multiple
>threads. Couldn't reproduce it as simply as above...
>
>As most of it is in XS, I won't be able to help you much there...
Just producing ways to reporoduce the problem (ideally as tests)
is a huge help.
>
>
>> >- threads->yield doesn't seem to yield.
>> >This means you're burning CPU needlessly until your timeslice is over.
>>ick - can we find something that _does_ yield?
>
>You mean an OS that yields()?
No I mean something that will cause Linux to yield usleep(1) or
a select() with a 1ms timeout or ...
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/
