Re: closing a channel

[nisse%lysator.liu.se@localhost (Niels Möller)]

I wrote:

> Can one send CHANNEL_REQUEST after EOF? I'd say yes. In particular,
> the order in which my server sends CHANNEL_EOF and CHANNEL_REQUEST
> "exit-status" depends on the the relative timing of i/o and the
> SIGCHLD signal, and is esssentially random. 

Let me provide an admittedly contrived, but I hope still illustrative,
example. Say we have a unix environment, and the server receives a
CHANNEL_REQUEST "exec" request on a session channel with the following
command line:

  "echo foo; exec >/dev/null; exec 2>/dev/null; sleep 30; exit 17"

The server forks and execs (assuming the user's login shell is
/bin/sh) the subprocess

  /bin/sh -c "echo foo; exec >/dev/null; exec 2>/dev/null; sleep 30; exit 17"

What my server will send to the client in this situation is

  CHANNEL_DATA "foo\n"     # The data the process sent to its stdout
  CHANNEL_EOF              # The process closed its stdout and stderr
  ... delay of about 30 seconds ...
  CHANNEL_REQUEST "exit-status" 17
  CHANNEL_CLOSE

I believe this is a reasonable use of the protocol, and it obviously
sends a CHANNEL_REQUEST long after the CHANNEL_EOF. What are the
alternatives?

* One could delay the CHANNEL_EOF until after the CHANNEL_REQUEST
  message. I think that's bad, there's no reson not to tell the client
  right away that it will get no more data on the channel.

* One could wait just a short while for the process to die, and if it
  doesn't die, just send CHANNEL_EOF and CHANNEL_CLOSE anyway.
  The client won't get any exit-status. This is ugly: For a start,
  what's a reasonable "short while"? It happens in practice that the
  server detects EOF before it gets to handle the SIGCHLD signal
  process death. I don't want a race-condition to determine whether or
  not the client gets any exit-status message (I've had such race
  conditions in the past, I hope I have fixed them by now).

* Brutally kill the process after we detect EOF, so we don't need to
  wait to send exit-status/exit-signal, or send a lying exit-status
  message.

I don't like any of these alternatives *at all*, and I believe the
behaviour described above, with CHANNEL_REQUEST "exit-status" sent a
while after CHANNEL_EOF, is the best and most natural way to report the
sequence of events to the client. Please don't ban it.

Best regards,
/Niels