Tcl Source Code

Nathan,

Starting with your last comment,

*I think one thing we can all agree on is that if a device signals that its
ready for a write...*

To expand on that, I think we can all agree none of the current proposals are
ideal. My concern with a broader, "better" solution has always been one of
timing w.r.t 9.0 release. I have reiterated my concerns with the current
implementation often enough. Alternative (1) below seems less risky in
comparison to a more complete solution because of 8.6 history (notwithstanding
any the other refchan bugs, restricting discussion to the issue in this ticket).
Similarly, alternative (2) below seems less risky because the channel subsystem
must in any case be presumed to work correctly with -buffering none. If it does
not, that is something to be fixed irrespective of refchans or anything else. If
someone has the time to work through the details, and sufficient review, a more
complete solution is certainly something desirable. I just do not want to hold
up 9.0 for this ideal scenario. If you take a stab at this (I'm still
prioritizing getting my extensions and distributions 9.0-ready), it would
certainly be a worthwhile exercise.

As to the other points,

Nathan wrote *If you can eliminate that timer without breaking anything, than
please do! What I'm arguing against is just reverting this change without
providing any other fix, and without even providing an example of something that
is broken and can't be fixed by any of the existing knobs.*

I already suggested two solutions

1. For the refchan to generate the event (off a timer). Why is this better than
the way it is done currently within the channel core? Because (a) the refchan
has better information about connection state, and (b) it only affects refchans
where this is needed, not ALL channels (refchans or not).

2. Implicitly setting -buffering none on refchans.

I already stated neither is ideal, I prefer (1), but both are better than what we
currently have.

I am waiting for you to specifically state what breaks with either of the above
or at least some technical reasons in opposition. The two objections I have heard
are:

- *That would be a knee-jerk reaction to a particular problem rather than a
well-considered design*.

- Paraphrasing my understanding of you stated, *Scripts should not be burdened
with the responsibility*.

With regards to the first, it's difficult for me to translate an opinion to a
broken behaviour or technical objection I can rationally discuss.

With regard to the second, if the refchan is implemented in
scripts, only the script knows channel state, and **must** own the
responsibility of generating events. Even with refchan enhancements, this would
still be true; the core could generate events but the information about state
would still have to be provided by the refchan through an enhanced API.

Moreover, your comments on how twapi or 14.11 or port scanners user code should
be written actually **burdens scripts with changing valid code to workaround the
bugs introduced by an attempt to reduce their burden**! The irony!

Nathan wrote *The problem is that Tcl writes to a buffer without actually
calling the [write] procedure that a refchan provides.*

Yes, and -buffering none on refchans, implicitly or explicitly, forces that
write, thereby resolving the issue for refchans!

Nathan wrote: *No one has made test io-14.11.0 reliably fail in the error case,
so it's currently not a meaningful test.*

I've already commented on this "meaningful" criterion for tests in
[b7f4b5a3f4](https://core.tcl-lang.org/tcl/info/b7f4b5a3f4a34b37). If we
have different opinions of what a meaningful test is, so be it. I will
give another example of where socket connection open checks are important
**before** doing any I/O on the channel (as in some of your examples that
do puts). Applications, for example, may want to protect against DNS spoofing
with reverse DNS lookups. This must be done before **any* io on the channel,
including output. When the connection open notification is received, the
peer address must be available. This will not work with premature connection
opens. (I understand you proposed buffer checks may fix this premature
notification problem but want to insist 14.11 not be dismissed as meaningless
in its intent or its implementation.)

Now coming to those additional proposed buffer checks,

Nathan wrote *The timer can be constrained to cases where a write (perhaps only
to a buffer) has already occurred and an unfilled buffer exists.*

I saw that in commit
[70a407c245](https://core.tcl-lang.org/tcl/info/70a407c2453e5aa3). (I missed the
comment in some other ticket; one consequence of discussion being spread across
three tickets). I'm afraid this only illustrates the problem with the current
design. It forces the channel core to **attempt to deduce information it does
not have**. Here it is attempting to figure out channel state based on buffer
state. Not only is this just a "guess", you have now made event generation a
dependency on the buffer management code. A change to preallocate channel
buffers, for example, would break this "guess". In SE terms, high coupling
between components that are conceptually independent. This is not good design
for maintainability.