develooper Front page | perl.perl5.porters | Postings from July 2002

Re: Thread::Use - use a module inside a thread only

Thread Previous | Thread Next
Elizabeth Mattijsen
July 30, 2002 06:25
Re: Thread::Use - use a module inside a thread only
Message ID:
At 02:10 PM 7/30/02 +0100, Nicholas Clark wrote:
> > As I said, as a simple solution for now, I think a:
> >    sub CLONE { undef( %PerlIO::gzip:: ) }
> > or equivalent of that in XS code would be sufficient to get around the
> > current problem of having to start your threads before you can open a
> > PerlIO::gzip layer...
>I believe that this won't work. Nor the direct XS equivalent. It will hide
>the problem:
>Once an IO layer is created, it is a free standing object attached to a
>stream. It doesn't matter if you "nuke" the module in the symbol table -
>you still have existing PerlIO structures pushed on existing streams that
>don't get killed this way.

Then maybe it should become possible to indicate that a PerlIO _structure_ 
should never be cloned?  So it never gets to the part where it attempt to 
clone it?

>And the PerlIO system defaults to doing a shallow structure copy (much like
>the default in C++ for copying objects) to make a copy of every layer for
>the new chain of layers in the layer stack. And to clone safely PerlIO::gzip
>needs to implement a deep copying constructor. And zlib doesn't provide
>one for inflate streams (I've checked - deflateCopy copies the internal state
>for deflation streams, and the internal state differs)

So, we put in a flag that the PerlIO structure doesn't get cloned.  This 
would probably fix problems with other PerlIO:: modules...  And the flag 
could be set by the PerlIO:: module itself!

So instead of trying to find a solution to the problem, try to prevent the 
problem from ever happening...

(hope this made sense...)


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About