Balazs Scheidler <[EMAIL PROTECTED]> writes:
> This counter is incremented if a read_data object gets a reference to a
> given channel, and decremented by a close_callback: channel_close_callback
> (used on fds whose destination is a channel).
I just added a paragraph to doc/NOTES to explain how this is supposed
to work.
: EOF ON CHANNELS
:
: A typical channel (i.e. all channels created in the current
: implementation) are, at each end, connected to one or more fd:s for
: reading and writing. When the source fd(:s), i.e. the fd:s that we are
: reading, have no more data available, a CHANNEL_EOF message should be
: sent. As there may be several such fd:s, we use a counter SOURCES in
: the channel struct to keep track of the number of active source fd:s.
: When an fd is closed, the counter is decremented, and when it reaches
: zero, the CHANNEL_EOF message is sent.
:
: The decrementing of the counter is done by the close-callback for the
: fd, not by the read handler, as this is the easiest way to
: ensure that it is called exactly once whenever a fd dies. However, the
: sending of the CHANNEL_EOF massage is done by the read handlers
: do_channel_write() and do_channel_write_extended(). This is because
: otherwise, eof on bidirectional fd:s migth be delayed until it is
: closed also for writing. There are more unsolved issues with
: bidirectional fd:s though, in particular tcp connections where one
: direction is closed (with shutdown()) long before the other.
> So read_data (incrementing the counter) is used on the stdout & stderr,
> and channel_close_callback (decrementing the counter) is used on stdin.
It seems the current code is terribly broken. This close callback
should be on stdout and stderr (and on the client side, on stdin).
A somewhat related problem is i/o errors on the other direction. If
data that arrives on a channel is sent to an fd, and writing to that
fd failes, what are we supposed to do? I think the right thing would
be to propagate something like "broken pipe" to the other end, but
there's no such mechanism in the protocol. Perhaps the best we can do
is to send a CHANNEL_CLOSE message to terminate the channel, and then
send a DEBUG message explaining what happened?
/Niels
