Mail Archives: cygwin/2015/06/06/20:04:03
--Multipart=_Sun__7_Jun_2015_09_03_29_+0900_uCisFul7s9sLIaAq
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
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 AT releng1 DOT nyi DOT freebsd DOT 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 DOT yano AT nifty DOT ne DOT 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 DOT yano AT nifty DOT ne DOT jp>
--Multipart=_Sun__7_Jun_2015_09_03_29_+0900_uCisFul7s9sLIaAq
Content-Type: application/x-gtar;
name="pipe_pty_test.tgz"
Content-Disposition: attachment;
filename="pipe_pty_test.tgz"
Content-Transfer-Encoding: base64
H4sIAJUscFUAA+1a/2/aRhTPr/ivOLGsMi0Qf4WNhKkaU6VJTTctmaopq5Br
n8upxkY+E5pM+d93X3zGQEjpEPaI3kdRbZ/ffe753flz71HPyAyP065/ckAY
DD3H4Uez7xriyP5EOz+3befEtFzbMSzX4vdNBvsEGYd0SmFOMy9F6OTOi5On
7N4lMa7Cn4rxHYn9aB5gdEGzgCTdyU/aSlNEPq62zWPCmtfsyKfYi1bbcJrG
63R39GzhkYy3arcJCRDrOJ54cRDhVCdxxq9b2j9aI5yl7DLU2UiMp42acoQB
+j74O262hd259qBpvNPUI7EuuvGrMLixPpxrDX/CpvXjPLwxDcvhDfxmirP8
jJxrWoNdoiGasVdAD4MWvxMiXTQOUcdsIUbZmDEHklRvCqtWk1s18BeS6cyA
nT8UNGGSftbLJBfIWKWQFo9QqC7MHJ29RL97KWYuvjxjdn6UUO7djfFB9JvT
COOZboo3R7QUFqa04BHW3/359q24YqzzNEZG7ipjH01IFAhy5g/SydA4R+SC
EbLDq1fSYxlunbTLM6Qed21AMdHs+fkQMhIp9gLpcpvPACe5x0mos/MW77Ex
u38UE8uDUA7hcD2GglvG8EFbj45Welzmad3v1jGAL+vxol795+dc/y3HdU2z
J/XfBf2vAofX/4Mr/eGEfV+BNLYI5CIlWa6g7IkN07Idt9f/4UfxxKb5qEa+
310jJf2mSJogkoA1zLK78bTm/N+17CL/t22Z/zs90P8qsLP+hwEO0Xj8JsX4
56tfxuOSGbOZZ0TqP44oLt1iy0s2xwEJj6iKmHo0w6wLjbxb/E3VRDLDMXtq
/YWieCE42oin5OV/v7ItKZ66Sg7p/pM1h3iwKmuOYsAtNYcK+U5Fx+WeVccy
QMe8owr9rzn/N3v9Zf7f7wv970P+XwmORf8rU/qahf1Q+ihrAuX6jjXH5b5F
x/PQyOcMrv+09vzfKvJ/x3CE/rug/5XgWPQf8v+K8/9lcr8t/S9VCBXl/8sR
txQAeah3yv+v9sz/iwAd9dYm9L/2/L9X5P+W7UL+XyGORf8h/99TH2V+nru8
Y/5/tW/+/zw08jlD/P7j16v/PcdU+X/PyPXfhu9/KsGx6P9q/k8SP4v+B2UB
VAG1VgHy+SnOKAmejoCyUduT7CmWkdoTr3/9bXQ1ur7+q42MJ7lkr8K84Nzc
c/OYWUXMFEV+Q3atdau89D7jkEQHlbav6X+fab7Sf8uwpP47oP9VwIuY8ImP
wFJ5WCD5SYA8yCsqr2h+z9c0P8JePGBLdYo64Tf0Lwi81J+QW6zG7vpIfYmG
1CcJSP3fFFI/UiJVrSKVtmgNPnv+/W3uBG/PMM262af7PamRejU0jTP+hyg1
Xs9jb4pRx2On2J8kqDkcys+SxM8VTPAVmsyieyZH2DQWuTV6zHixapzd5VvU
kj83Ft5uMy74S8abzEKhSo4vjekmszReOl4y3uqzEMI1N9hSkVFZrhStcaqP
Ri3Uec8WLzq9QJ0Enb7O7RaDYra32olYDIrF8Lgd6kQ8qcnNF4NiyexgTnN2
uhs7zdnpbuxTf1Ba/0+Z1y0uAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
KsG/1ieiggBQAAA=
--Multipart=_Sun__7_Jun_2015_09_03_29_+0900_uCisFul7s9sLIaAq
Content-Type: application/octet-stream;
name="cygwin.patch.20150604"
Content-Disposition: attachment;
filename="cygwin.patch.20150604"
Content-Transfer-Encoding: base64
ZGlmZiAtLWdpdCBhL3dpbnN1cC9jeWd3aW4vZmhhbmRsZXJfdHR5LmNjIGIv
d2luc3VwL2N5Z3dpbi9maGFuZGxlcl90dHkuY2MKaW5kZXggMWI1YzE4Yi4u
ZjIyOTk4ZiAxMDA2NDQKLS0tIGEvd2luc3VwL2N5Z3dpbi9maGFuZGxlcl90
dHkuY2MKKysrIGIvd2luc3VwL2N5Z3dpbi9maGFuZGxlcl90dHkuY2MKQEAg
LTYyMiw3ICs2MjIsNiBAQCBmaGFuZGxlcl9wdHlfc2xhdmU6OndyaXRlIChj
b25zdCB2b2lkICpwdHIsIHNpemVfdCBsZW4pCiAJZGVmYXVsdDoKIAkgIF9f
c2V0ZXJybm9fZnJvbV93aW5fZXJyb3IgKGVycik7CiAJfQotICAgICAgcmFp
c2UgKFNJR0hVUCk7CQkvKiBGSVhNRTogU2hvdWxkIHRoaXMgYmUgU0lHVFRP
VT8gKi8KICAgICAgIHRvd3JpdGUgPSAtMTsKICAgICB9CiAgIHJldHVybiB0
b3dyaXRlOwpAQCAtNzQ5LDcgKzc0OCwxMiBAQCBmaGFuZGxlcl9wdHlfc2xh
dmU6OnJlYWQgKHZvaWQgKnB0ciwgc2l6ZV90JiBsZW4pCiAJICBnb3RvIG91
dDsKIAl9CiAgICAgICBpZiAoIWJ5dGVzX2F2YWlsYWJsZSAoYnl0ZXNfaW5f
cGlwZSkpCi0JcmFpc2UgKFNJR0hVUCk7CisJeworCSAgUmVsZWFzZU11dGV4
IChpbnB1dF9tdXRleCk7CisJICBzZXRfZXJybm8gKEVJTyk7CisJICB0b3Rh
bHJlYWQgPSAtMTsKKwkgIGdvdG8gb3V0OworCX0KIAogICAgICAgLyogT24g
Zmlyc3QgcGVlayBkZXRlcm1pbmUgbm8uIG9mIGJ5dGVzIHRvIGZsdXNoLiAq
LwogICAgICAgaWYgKCFwdHIgJiYgbGVuID09IFVJTlRfTUFYKQpAQCAtNzc5
LDkgKzc4MywxMCBAQCBmaGFuZGxlcl9wdHlfc2xhdmU6OnJlYWQgKHZvaWQg
KnB0ciwgc2l6ZV90JiBsZW4pCiAJICBpZiAoIVJlYWRGaWxlIChnZXRfaGFu
ZGxlICgpLCBidWYsIHJlYWRsZW4sICZuLCBOVUxMKSkKIAkgICAgewogCSAg
ICAgIHRlcm1pb3NfcHJpbnRmICgicmVhZCBmYWlsZWQsICVFIik7Ci0JICAg
ICAgcmFpc2UgKFNJR0hVUCk7Ci0JICAgICAgYnl0ZXNfaW5fcGlwZSA9IDA7
Ci0JICAgICAgcHRyID0gTlVMTDsKKwkgICAgICBSZWxlYXNlTXV0ZXggKGlu
cHV0X211dGV4KTsKKwkgICAgICBzZXRfZXJybm8gKEVJTyk7CisJICAgICAg
dG90YWxyZWFkID0gLTE7CisJICAgICAgZ290byBvdXQ7CiAJICAgIH0KIAkg
IGVsc2UKIAkgICAgewpAQCAtNzkwLDcgKzc5NSwxMiBAQCBmaGFuZGxlcl9w
dHlfc2xhdmU6OnJlYWQgKHZvaWQgKnB0ciwgc2l6ZV90JiBsZW4pCiAJCSBj
aGFuZ2UgYWZ0ZXIgc3VjY2Vzc2Z1bCByZWFkLiBTbyB3ZSBoYXZlIHRvIHBl
ZWsgaW50byB0aGUgcGlwZQogCQkgYWdhaW4gdG8gc2VlIGlmIGlucHV0IGlz
IHN0aWxsIGF2YWlsYWJsZSAqLwogCSAgICAgIGlmICghYnl0ZXNfYXZhaWxh
YmxlIChieXRlc19pbl9waXBlKSkKLQkJcmFpc2UgKFNJR0hVUCk7CisJCXsK
KwkJICBSZWxlYXNlTXV0ZXggKGlucHV0X211dGV4KTsKKwkJICBzZXRfZXJy
bm8gKEVJTyk7CisJCSAgdG90YWxyZWFkID0gLTE7CisJCSAgZ290byBvdXQ7
CisJCX0KIAkgICAgICBpZiAobikKIAkJewogCQkgIGxlbiAtPSBuOwpAQCAt
MTI2OSw2ICsxMjc5LDggQEAgZmhhbmRsZXJfcHR5X21hc3Rlcjo6Y2xvc2Ug
KCkKICAgZWxzZSBpZiAob2JpLkhhbmRsZUNvdW50ID09IDEpCiAgICAgewog
ICAgICAgdGVybWlvc19wcmludGYoIkNsb3NpbmcgbGFzdCBtYXN0ZXIgb2Yg
cHR5JWQiLCBnZXRfbWlub3IgKCkpOworICAgICAgaWYgKGdldF90dHlwICgp
LT5nZXRzaWQgKCkgPiAwKQorCWtpbGwgKGdldF90dHlwICgpLT5nZXRzaWQg
KCksIFNJR0hVUCk7CiAgICAgICBTZXRFdmVudCAoaW5wdXRfYXZhaWxhYmxl
X2V2ZW50KTsKICAgICB9CiAK
--Multipart=_Sun__7_Jun_2015_09_03_29_+0900_uCisFul7s9sLIaAq
Content-Type: text/plain; charset=us-ascii
--
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
--Multipart=_Sun__7_Jun_2015_09_03_29_+0900_uCisFul7s9sLIaAq--
- Raw text -