From: SourceForge.net <no...@so...> - 2010-01-21 13:22:40
|
Bugs item #2936225, was opened at 2010-01-21 22:44 Message generated for change (Comment added) made by coldstore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2936225&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 24. Channel Commands Group: None Status: Open Resolution: None Priority: 8 Private: No Submitted By: Colin McCormack (coldstore) Assigned to: Alexandre Ferrieux (ferrieux) Summary: [chan copy] overruns slow receiver Initial Comment: If (for example) a file is fed to a socket using [chan copy], where input from the file is always available and output is only sometimes available, [chan copy] seems to buffer input in memory without regard for the disparity between input and output. The effect of this is that, for a very large file, all memory can be consumed in buffered content, and tcl can fail on memory allocation. Perhaps [chan copy] should have regard to the output file's buffer, and not seek to fill more than that buffer specifies. This won't solve the memory exhaustion problem, but might be a sound way to indicate expected performance of the output chan. ---------------------------------------------------------------------- >Comment By: Colin McCormack (coldstore) Date: 2010-01-22 00:22 Message: One possibly important detail is that the output (socket) chan in the case we (think) we observe causing this is configured non-blocking, binary. Does this make any difference? ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2010-01-22 00:04 Message: Hum, cannot seem to repro (Linux Fedora 12, unthreaded, 8.6 HEAD). FWIW, [chan copy]'s mechanism is one of alternating readable and writable fileevents, precisely to avoid accumulating data as you describe. I've tried both sync and async fcopy, reading from a local file and outputting to a blocked stdout (tclsh script.tcl | sleep 9999), in both cases Tcl stops reading shortly after the beginning (typically after reading 68K of input). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2936225&group_id=10894 |