| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In a DoRead() revision, it came to favor making every effort to fill
buffers, in preference to a more sensible goal of favoring avoiding calls
out to the driver if there's already enough data in the buffers to satisfy
the read operation. Result is many more calls out to recv() than are
a good idea. Ought to show up most glaringly when many Tcl_Read() calls
asking for small numbers of bytes (compared to buffer size) each, and that
matches the reported case.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
will be called back with a mask value. "Mask is an integer mask indicating
which of the requested conditions actually exists for the channel; it will
contain ***a subset of the bits from the mask argument*** to
Tcl_CreateChannelHandler when the handler was created." (emhpasis added).
Tcl_NotifyChannel is not honoring this. It passes a mask value that may
contain bits not in common with the mask argument to T_CCH().
This commit is a one-liner patch adding in the masking step to make things
behave as documented. Thanks to apn for digging this out. (In combination
with other questionable code, this led to a hang in test http-4.6 on Windows)
Tcl_NotifyChannel() has had this error in all of recorded Tcl history.
It's hard to imagine any code dependent on it though. If any exists, it
can be revised to pass the mask value it truly needs to T_CCH() and end up
with code suitable both before and after this change.
If you concur, please merge to core-8-5-branch, and I'll take it from there.
|
| |
| |
| |
| |
| | |
[read] on a channel @ EOF to attempt another pass through the channel drivers
instead of immediately returning an empty string. Correcting this misbehavior
appears too disruptive in a patch release to a long stable branch.
|
| | |
|
|\ \
| |/ |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
identifiers "macosx*-i386-x86_64" and "macosx-universal" as
incompatible with each other.
Plus addition of a cast in tclIO.c to match types in a comparison
which otherwise bugs a Windows debug build (warnings are errors).
|
| |\
| |/
|/| |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| | |
Reduce code duplication.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
compatibility!
|
| | |
|
| | |
|
|\ \ |
|
| |\ \
| | |/ |
|
| | | |
|
|/ /
| |
| | |
efficient [chan copy].
|
|\ \
| |/
| | |
a nonblocking channel is blocked.
|
| |
| |
| | |
a nonblocking channel is blocked.
|
|\ \
| |/ |
|
| | |
|
|\ \
| |/ |
|
| | |
|
|\ \
| |/
| |
| | |
right on the next pass, don't forget the TCL_UTF_MAX padding demanded by Tcl_ExternalToUtf(). (Thanks for finding that, aku!) Fix the factorPtr management. It was just totaly wrong. The factor should be a ratio of the record of bytes read to the record of chars read. With those fixes, new test io-12.6 covers the "too many chars" code.
|
| |
| |
| |
| |
| |
| |
| | |
get it right on the next pass, don't forget the TCL_UTF_MAX padding
demanded by Tcl_ExternalToUtf(). (Thanks for finding that, aku!)
Fix the factorPtr management. It was just totaly wrong. The factor should
be a ratio of the record of bytes read to the record of chars read.
With those fixes, new test io-12.6 covers the "too many chars" code.
|
|\ \
| |/
| |
| | |
FlushChannel() which is its only caller. We need to discard the curOutPtr buffer as well, and not count on another pass through the loop to attempt to flush it (and raise the same failure again?).
|
| |
| |
| |
| |
| | |
which is its only caller. We need to discard the curOutPtr buffer as well,
and not count on another pass through the loop to attempt to flush it
(and raise the same failure again?).
|
| |\
| |/
|/| |
|
| |
| |
| |
| | |
Several socket-14.* tests failing there, and those that pass are very slow
about it. Firewall or poor networking configuration may be playing a role.
|
| |
| |
| | |
a whole raft of test failures. WIP.
|
|\ \
| | |
| | |
| | | |
PipeWatchProc(). When we are interested in both readable and writable events of a command pipeline channel, we only want the readable from the read end of the pipe, and the writable from the write end of the pipe.
|
| |/
| |
| |
| |
| | |
PipeWatchProc(). When we are interested in both readable and writable
events of a command pipeline channel, we only want the readable from
the read end of the pipe, and the writable from the write end of the pipe.
|
|\ \
| |/
| |
| | |
the flag BUFFER_READY.
|
| |\
| | |
| | | |
of the flag BUFFER_READY.
|
| | | |
|
| | |
| | |
| | | |
BUFFER_READY flag serves no necessary purpose, so it is removed.
|
| | | |
|
| | |
| | |
| | |
| | | |
the OS networking machinery gets backed up and blocks.
Added several TODO comments on potential simplifications.
|
| |/ |
|
| | |
|
| | | |
| \ | |
|\ \ \
| | |/
| | |
| | | |
particular not allowing them to leak between multiple layers of a stacked channel. Much common code refactored into ChanRead().
|
| | |\
| | | |
| | | |
| | | | |
particular not allowing them to leak between multiple layers of a stacked
channel. Much common code refactored into ChanRead().
|