Tcl Source Code

Hi!

I've tried to use [zlib push decompress] on an unblocked network channel and found that it doesn't read from the channel if it isn't closed by the peer. In the attached script the server part puts two strings into a compressed channel (one immediately and the other after 5 second delay). Apparently, the client side readable fileevent fires many times during these 5 seconds but [read $chan] returns empty string every time. After the finishing [close] the client reads and reports the message (but only the second one!).

I would expect the both messages were printed.

Currently, I can use a separate [zlib stream decompress] and read the raw bytes from the channel, but I don't think that it's a perfect solution.

allow_comments - 1

Thanks to everyone who worked on this; fix merged to trunk

Test committed to the branch.

Having looked at https://core.tcl.tk/tcl/vdiff?from=ba6087ec84&to=c003b262df77ede3
It looks reasonable. (I'll want to tinker with it after merger to reduce the apparent complexity, but I'll not cause this fix to be delayed for that.)

Before commit back, do we have a test for this yet?

I confirm that after the applying the attached patch the bug is gone.

Committed change to branch bug-3525907, rev. 5ffc93920daf1775e96132f6fd826e735d84028b and descendants.

The attached patch seems to fix the issues, and passes the testsuite for me.
Please test.

File Added - 443826: zlib-reworked-without-instrumentation.patch

Moving the 

   chan configure $chan -flush sync

before the puts of the first message (still after the zlib transform is pushed) gets us both messages on the receiver side. I.e. no loss of bytes anymore. It still receives them only when the channel is closed.

I suspect that the "-flush sync" (is intended to) activate(s) the special zlib flush code forcing out the data buffered in the zlib transform without ending the zlib stream.

This part doesn't seem to work correctly.

I confirm both the strange disappearance of the bytes written before [-flush sync], and a worrisome level of syscall activity during all the 5 seconds of what should be a completely quiescent delay. Clearly, continued exchanges between the notifier and main thread occur, with a period of 7 ms. Looks like a "tamed busy loop", but I don't like it :/

File Added - 443236: zlibtest2.tcl

File Added - 443234: zlibtest1.tcl