|
2012-05-23
| ||
| 21:35 | • Closed ticket [3525907fff]: zlib push decompress doesn't work with fileevent readabl plus 7 other changes artifact: b4d88d5bc5 user: dkf | |
|
2012-05-21
| ||
| 03:52 | • Ticket [3525907fff]: 4 changes artifact: beede78bef user: ferrieux | |
|
2012-05-19
| ||
| 20:15 | • Ticket [3525907fff]: 4 changes artifact: d1e881aab5 user: dkf | |
|
2012-05-18
| ||
| 12:16 | • Ticket [3525907fff]: 4 changes artifact: 4d4254d8a6 user: teopetuk | |
| 04:47 | • Ticket [3525907fff]: 4 changes artifact: b4d269cf4c user: andreas_kupries | |
| 04:31 | • Ticket [3525907fff]: 4 changes artifact: 12646cd9ac user: andreas_kupries | |
| 04:30 | • Add attachment zlib-reworked-without-instrumentation.patch to ticket [3525907fff] artifact: 6591dcff86 user: andreas_kupries | |
| 04:30 | • Ticket [3525907fff] zlib push decompress doesn't work with fileevent readabl status still Open with 4 other changes artifact: 75e2578044 user: andreas_kupries | |
|
2012-05-17
| ||
| 01:21 | • Ticket [3525907fff]: 4 changes artifact: dcb1a738ea user: andreas_kupries | |
|
2012-05-13
| ||
| 22:31 | • Ticket [3525907fff]: 5 changes artifact: a9bd355b04 user: ferrieux | |
|
2012-05-12
| ||
| 00:29 | • Add attachment zlibtest2.tcl to ticket [3525907fff] artifact: a6d3425344 user: teopetuk | |
| 00:29 | • Ticket [3525907fff] zlib push decompress doesn't work with fileevent readabl status still Open with 4 other changes artifact: 476d0ca368 user: teopetuk | |
| 00:27 | • Ticket [3525907fff]: 4 changes artifact: f28e4daa42 user: teopetuk | |
| 00:27 | • Add attachment zlibtest1.tcl to ticket [3525907fff] artifact: a3fa0c8d60 user: teopetuk | |
|
2012-05-11
| ||
| 17:27 | • New ticket [3525907fff] zlib push decompress doesn't work with fileevent readabl. artifact: f46a576bbe user: teopetuk | |
| Ticket UUID: | 3525907 | |||
| Title: | [zlib push decompress] doesn't work with [fileevent readabl] | |||
| Type: | Bug | Version: | obsolete: 8.6b2 | |
| Submitter: | teopetuk | Created on: | 2012-05-11 17:27:33 | |
| Subsystem: | 57. zlib | Assigned To: | dkf | |
| Priority: | 9 Immediate | Severity: | ||
| Status: | Closed | Last Modified: | 2012-05-23 21:35:14 | |
| Resolution: | Fixed | Closed By: | dkf | |
| Closed on: | 2012-05-23 14:35:14 | |||
| Description: |
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. | |||
| User Comments: |
dkf added on 2012-05-23 21:35:14:
allow_comments - 1 Thanks to everyone who worked on this; fix merged to trunk ferrieux added on 2012-05-21 03:52:54: Test committed to the branch. dkf added on 2012-05-19 20:15:11: 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? teopetuk added on 2012-05-18 12:16:31: I confirm that after the applying the attached patch the bug is gone. andreas_kupries added on 2012-05-18 04:47:42: Committed change to branch bug-3525907, rev. 5ffc93920daf1775e96132f6fd826e735d84028b and descendants. andreas_kupries added on 2012-05-18 04:31:13: The attached patch seems to fix the issues, and passes the testsuite for me. Please test. andreas_kupries added on 2012-05-18 04:30:28: File Added - 443826: zlib-reworked-without-instrumentation.patch andreas_kupries added on 2012-05-17 01:21:30: 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. ferrieux added on 2012-05-13 22:31:44: 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 :/ teopetuk added on 2012-05-12 00:29:03: File Added - 443236: zlibtest2.tcl teopetuk added on 2012-05-12 00:27:35: File Added - 443234: zlibtest1.tcl | |||