in reply to Re: Re: The Singleton design pattern and fork();
in thread The Singleton design pattern and fork();
First, it does work under 5.8 and it doesn't work under 5.6.1.
My best explaination for the difference in behaviour, and with luck Elian will browse past and set me straight if I have it wrong, is the use of the shared attribute. The clue, beyond my observations, is the documentation for threads::shared which states under the heading BUGS
Does not support splice on arrays!Taking references to the elements of shared arrays and hashes does not autovivify the elements, and neither does slicing a shared array/hash over non-existent indices/keys autovivify the elements.
The assumption I am making is that, in order to allow disperate threads to share variables, assignments to them 'update inplace' rather than allocating a new scalar and then swapping the pointers and letting the GC take care of the cleanup.
That this is noted under bugs means the fact that it worked in the first place is basically happenstance and is not a behaviour I or anyone else should rely upon. As such I will be going back and changing it to
$_-- for @flags;
which would probably have been a better choice in the first place.
Thankyou for pointing this out. You were especially observant if you have not yet made the transition to perls threads. ++
Interestingly enough, the docs for threads::shared also state that the module will also work for Win32 pseudothreads and fork on that platform, which has possibilities if that is your platform.
|
|---|