On tisdag, juli 30, 2002, at 03:24 , Elizabeth Mattijsen wrote:
>
> 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
No, the correct approach is to clone perlio structures.
Arthur
