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: cygwin-2 process handling (about SIGHUP)


Hi Corinna,

On Thu, 28 May 2015 16:16:12 +0200 Corinna Vinschen wrote:

> I applied this patch.  I'm not comfortable with removing the SIGHUP
> handling from slave::read in favor of just setting errno to EIO.
> EIO seems wrong here.  Not being able to access the pipe anymore
> should be equivalent to a hangup.  Alternatively the return code
> from the Windows function should be checked for ERROR_BROKEN_PIPE,
> perhaps, but that introduces some more code,

Regarding SIGHUP, I have a different thought.

I have checked the behaviour of PTY on other systems than cygwin.
However, no system raises SIGHUP on the read()/write() access to
PTY, of which the other side is closed. But on the close() in the
master side, only when the slave side of the PTY is the controlling
terminal, SIGHUP is sent to the slave side.

I have tested on Debian GNU/Linux and FreeBSD as well as Cygwin.

The test case is as attached (pipe_pty_test.tgz). The testing
procedure is as follows.

tar xzvf pipe_pty_test.tgz
make
make test

This test case checks how the PTY behaves when the other side
of the PYT is closed. As a comparison, behaviour of pipe is
also tested.

On Debian, the result is:
Linux debian 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24) i686 GNU/Linux
=== pipe read ==========
R: 0
read(): Success
=== pipe write =========
signal: 13
W: -1
write(): Broken pipe
=== pty master read ====
MR: -1
read(): Input/output error
=== pty master write ===
MW: 11
=== pty slave read =====
SR: -1
read(): Input/output error
=== pty slave write ====
SW: -1
write(): Input/output error
=== pty master close ===
signal: 18
signal: 1
usleep(): Interrupted system call


On FreeBSD, the result is:
FreeBSD FreeBSD-VM 10.1-RELEASE FreeBSD 10.1-RELEASE #0 r274401: Tue Nov 11 22:51:51 UTC 2014     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  i386
=== pipe read ==========
R: 0
read(): No error: 0
=== pipe write =========
signal: 13
W: -1
write(): Broken pipe
=== pty master read ====
MR: 0
read(): No error: 0
=== pty master write ===
MW: 11
=== pty slave read =====
SR: 0
read(): No error: 0
=== pty slave write ====
SW: -1
write(): Device not configured
=== pty master close ===
signal: 1
usleep(): Interrupted system call


However, on cygwin, the result is:
CYGWIN_NT-6.1-WOW Express5800-S70 2.0.3(0.287/5/3) 2015-06-03 13:55 i686 Cygwin
=== pipe read ==========
R: 0
read(): No error
=== pipe write =========
signal: 13
W: -1
write(): Broken pipe
=== pty master read ====
MR: -1
read(): Input/output error
=== pty master write ===
MW: 11
=== pty slave read =====
signal: 1
SR: 0
read(): No error
=== pty slave write ====
signal: 1
SW: -1
write(): Input/output error
=== pty master close ===
usleep(): No error


On cygwin, extra SIGHUPs (signal: 1) are generated in the pty-
slave-read case and in the pty-slave-write case. On the contrary,
SIGHUP is not generated in the pty-master-close case while it
is generated on other systems. On the Debian, SIGCONT (signal:
18) is also sent in the pty-master-close case.

Although SIGHUP on the master closure was pointed out in the
past: https://www.cygwin.com/ml/cygwin/2011-07/msg00328.html,
it was not adopted at that time.

In the track of Debian/FreeBSD, SIGHUP should not be generated
on the read()/write() access on the slave side, but should be
generated on the close() on the master side, only when the slave
side of the PTY is the controlling terminal.

It seems that this behaviour is specified in the POSIX standard.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/close.html

To make the behaviour match with the test results on other
systems, I have made a patch attached (cygwin.patch.20150604).

With this patch, everything works nicely for me as well.

Furthermore, with this patch, mc (midnight commander) becomes
exiting normally. On cygwin 2.0.3-1, mc has a problem which
leaves a subshell process on the background.

To reproduce this problem, execute
env SHELL=/bin/bash mc
on cygwin 2.0.3-1, and type 'exit'.

You will find bash process remains in background. I have confirmed
this problem can be resolved by this patch.

For the reason above, I think it is better to make the behaviour
match with other systems as well as the POSIX specification.

What do you think?


ChangeLog is as follows.

2015-06-04  Takashi Yano  <takashi.yano@nifty.ne.jp>

	* fhandler_tty.cc (fhandler_pty_slave::write): Move causing of SIGHUP
	into fhandler_pty_master::close().
	(fhandler_pty_slave::read): Ditto.
	(fhandler_pty_master::close): Ditto.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Attachment: pipe_pty_test.tgz
Description: GNU Unix tar archive

Attachment: cygwin.patch.20150604
Description: Binary data

--
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]