I've been pursuing a problem on some platforms with the http package
handling compressed http streams. The problem is something to do with
fcopy and pushed zlib channels. Now I've come up with the following
proposed test:

test zlib-9.4 "socket fcopy (gzip)" -constraints zlib -setup {
    set srv [socket -server {apply {{c a p} {
        puts "connect from $a:$p"
        chan configure $c -encoding binary -translation binary
        puts -nonewline $c [zlib gzip [string repeat a 81920]]
        close $c
    }}} 0]
    set file [makeFile {} test.gz]
} -body {
    lassign [chan configure $srv -sockname] addr name port
    set sin [socket $addr $port]
    chan configure $sin -translation binary
    zlib push gunzip $sin
    update
    set fout [open $file wb]
    after 1000 {set ::total timeout}
    fcopy $sin $fout -command {apply {{c {e {}}} {
        set ::total [expr {$e eq {} ? $c : $e}]
    }}}
    vwait ::total
    close $sin; close $fout
    list read $::total size [file size $file]
} -cleanup {
    close $srv
} -returnCodes {ok error} -result {read 81920 size 81920}

If you comment out the zlib push line in the test body this will work
but the size of the copied data is the compressed size (obviously)
of 115 bytes. Note that this is under the size of the buffering size
of 4K.
When the zlib push is in effect fcopy will be expecting to be provided
with 81920 bytes. However it always hangs up and the timeout
terminates the test.
This matches what I see in the http package where the combination of
the -channel option and compression causes us to use fcopy from the
socket (including zlib pushed transform) to the output channel. In the
http case I see one block followed by an eof but there are more blocks
to be copied. If I ignore the eof and keep repeating the fcopy I
eventualy get all the data.
So my guess is that the channel framework recieves one chunk of 115
and generates a fileevent for the zlib transform which pushes a
buffersize block. Then its got eof but also has data buffered. For
some reason I reckon it is never generating further events for fcopy.

So. Is the above invalid for some reason? Should I be expecting this
to work differently. The only real difference between the above test
and what is used in the http package is that the http code uses style
3 from the fcopy man page (watches the progress by repeating the fcopy
call from the -command).

-- 
Pat Thoyts                            http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97  10 CE 11 E6 04 E0 B9 DD


------------------------------------------------------------------------------
_______________________________________________
Tcl-Core mailing list
Tcl-Core@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-core