From: SourceForge.net <no...@so...> - 2009-07-25 13:19:54
|
Bugs item #2827000, was opened at 2009-07-25 23:19 Message generated for change (Tracker Item Submitted) made by coldstore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2827000&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: 25. Channel System Group: development: 8.6b1.1 Status: Open Resolution: None Priority: 7 Private: No Submitted By: Colin McCormack (coldstore) Assigned to: Andreas Kupries (andreas_kupries) Summary: tcl incorrectly reports eof to application Initial Comment: attached is an annotated narrative log of an observed sequence of interactions by the refchan subsystem and this code http://code.google.com/p/wub/source/browse/trunk/Wub/Chan.tcl?r=1798 A connected socket is passed as the 'chan' argument of Chan construction, which is [chan create]d as a refchan. In the narrative, some data is [read] pursuant to a [readable] event on the underlying socket. Less data is returned by [Chan read] than is requested. A buffer-full of data is requested (4096 bytes) but only 1440 bytes are available. The data is processed by the application, which then attempts to [read] (in non-blocking mode?) more data. The application uses [gets] to parse a prefix of the 1440 bytes which are available, but it certainly does not consume the entirety. It attempts to [read] some 20Kb more. Tcl [Chan watch]es the refchan, and soon after calls [Chan read] again to request another buffer-full of data. There has been no readable event triggering, nor has [chan postevent] been called by Chan. Despite this, Tcl attempts to read. When there is no data available, as indicated by the return value of "" from [Chan read] upon this second attempt, Tcl indicates [eof] on the refchan. I would have expected Tcl not to call [Chan read] until after a [chan postevent] had been signalled to it by Chan. Observations: The behaviour is intermittent, insofar as sometimes an identical socket interaction succeeds (though rarely.) I have attempted to reproduce the behaviour in a localhost-connected socket, and failed. I believe this is because the second and subsequent [Chan read]s succeed. I think it's likely that Tcl refchan is calling the refchan's read method inappropriately, and then interpreting the 0-length result as end of file even though it has received no indication from the refchan by means of postevent that it can expect any data to be available to read. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2827000&group_id=10894 |