At 10:59 AM 7/30/02 +0100, Nicholas Clark wrote: > > Actually, the thing about PerlIO::gzip isn't true. You can't create > > threads with a PerlIO::gzip layer open currently. Even if you don't > need a > > PerlIO::gzip layer in the thread. There is no problem if you only want a > > PerlIO::gzip layer inside a thread only. So that is a different problem > > altogether. >I haven't looked at this thoroughly (actually, it's only been >cursory) but I think that cloning a layer open currently strictly requires >cloning zlib's struct. In turn, zlib's struct can contain dynamically >allocated structures, so they would have to be cloned too. Er, except >that zlib's struct is private to zlib. Conundrum.
Hmmm... do we _really_ want to be reading or writing gzipped files from different threads? I think that would really be asking for trouble... I think it would be really better for now if the cloning of an already opened gzip layer simply would just pop itself out of the PerlIO chain. Or even better, close the whole chain in the thread altogether. Probably with a warning if warnings are enabled. The problem right now is that if you want to read or write a gzipped file with the PerlIO::gzip layer, you need to wait until all threads are started and then open the files. This is because the threads will die because PerlIO::Gzip can't clone. Even if I don't need PerlIO::gzip inside the thread! >I think deflateCopy() may actually be the solution, if it copies all parts >of a z_stream whether being for inflation or deflation. >But it would have to make the new copy using a malloc() that allocates memory >from the new thread, wouldn't it? I have no idea. But I think synchronizing reads and writes from different threads would be a major task... ;-( Liz
