On Wed, 8 Dec 2010, Bram Moolenaar wrote:
Xavier de Gaye wrote:
On Mon, Dec 6, 2010 at 7:54 PM, Benjamin R. Haskell wrote:
If Vim receives a SIGWINCH (_sig_nal that the _win_dow _ch_anged
size) while editing stdin, a program piping input to Vim gets killed
prematurely. Is there an easy way to avoid this?
Actually, it is Vim that terminates prematurely.
This is a bug in Vim: when vim receives the SIGWINCH signal, the
vim_read() call that is reading stdin, returns -1 and vim handles
that as an error in readfile().
[...]
This looks like a hack. I think the proper solution is to have
vim_read() check for EINTR and retry.
I'm a bit confused about what happens when read() is interrupted
before reading anything, does it return zero or -1? Perhaps this
depends on the system.
""" from `man 2 read` (on OpenSUSE)
POSIX allows a read() that is interrupted after reading some data to
return -1 (with errno set to EINTR) or to return the number of bytes
already read.
"""
To me that implies, but doesn't explicitly state, that it *doesn't*
return the number of bytes read [which is 0] if it *hasn't* read any
bytes.
It also seems like it would conflict with being able to detect EOF.
Thus, I think it's safe to assume that an interrupted read() with no
returned data returns -1.
At least at some point vim_write() assumes it writes something before
being interrupted, that might be wrong as well.
Assuming vim_write is checking how much data is written, I think it's
okay:
""" from `man 2 write`
If a write() is interrupted by a signal handler before any bytes are
written, then the call fails with the error EINTR; if it is interrupted
after at least one byte has been written, the call succeeds, and returns
the number of bytes written.
"""
--
Best,
Ben
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
