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...)
Liz
