This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: SIGHUP on pty closure


On 25/07/2011 17.11, Christopher Faylor wrote:
On Mon, Jul 25, 2011 at 12:36:58PM +0200, Marco atzeri wrote:
On 7/21/2011 11:43 PM, Marco atzeri wrote:
looking on the mc subshell issue, I found that mc
suppose that the subshell will receive a SIGHUP
when mc exit and close the master side of pty.

Is such assumption wrong or it is a missing piece of
cygwin pty implementation ?



------------- extract from subshell.c --------------
/* Attach all our standard file descriptors to the pty */

/* This is done just before the fork, because stderr must still */
/* be connected to the real tty during the above error messages; */
/* otherwise the user will never see them. */

dup2 (subshell_pty_slave, STDIN_FILENO);
dup2 (subshell_pty_slave, STDOUT_FILENO);
dup2 (subshell_pty_slave, STDERR_FILENO);

close (subshell_pipe[READ]);
close (subshell_pty_slave); /* These may be FD_CLOEXEC, but just in
case... */
/* Close master side of pty. This is important; apart from */
/* freeing up the descriptor for use in the subshell, it also */
/* means that when MC exits, the subshell will get a SIGHUP and */
/* exit too, because there will be no more descriptors pointing */
/* at the master side of the pty and so it will disappear. */
close (subshell_pty);

/* Execute the subshell at last */

switch (subshell_type)
{
case BASH:
execl (shell, "bash", "-rcfile", init_file, (char *) NULL);
break;
----------------------------------------------------------

It seems that mc is correct in the expectation.


http://pubs.opengroup.org/onlinepubs/9699919799/functions/close.html

"If fildes refers to the master side of a pseudo-terminal, and this is
the last close, a SIGHUP signal shall be sent to the controlling
process, if any, for which the slave side of the pseudo-terminal is the
controlling terminal. It is unspecified whether closing the master side
of the pseudo-terminal flushes all queued input and output."


I don't find such implementation on cygwin


fhandler_pty_master::close ()

Am I looking in the wrong place ?

(checked into this a little more)


Sort of.  If the process is doing a read, it is supposed to detect that
the tty has been closed and a SIGHUP is supposed to be sent.  It is not
precisely the same thing as sending a SIGHUP when the master closes but
I'm surprised that, in principle, it doesn't amount to the same thing.

Just see any of the SIGHUPs in fhandler_tty.cc.  They are all supposed
to be dealing with this scenario.

So, unless bash is not waiting for input (which is unlikely) this should
work.

cgf

except if bash is sleeping and waiting for signal (or sort of)


http://www.gnu.org/software/bash/manual/bashref.html#Signals

The fact that sending SIGHUP (with $kill -SIGHUP bashpid)
triggers the bash exit, it seems an indication that cygwin is not
correctly handling the situation.

Otherwise there is a bug in bash, and not in mc ;-)

Marco



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]