# [tig PATCH] continue updates when pipe read has errno "Success" 3 messages from 2008-08-21 to 2008-08-22. Participants: Jeff King, Jonas Fonseca. Thread: https://gitlist.dev/t/15121 ## Jeff King, 2008-08-21 01:40 Subject: [tig PATCH] continue updates when pipe read has errno "Success" Message-ID: <20080821014043.GA14452@coredump.intra.peff.net> URL: https://gitlist.dev/e/20080821014043.GA14452%40coredump.intra.peff.net ``` When we are reading from a pipe and receive a signal, our read call fails and ferror() returns true. The current behavior is to call end_update and report failure. However, we can detect this situation by checking that errno is set to success and continue the reading process. You can provoke this behavior by running a "tig blame" that takes a few seconds and then resizing the terminal that tig is running in (you should get an incomplete blame output and the error "Failed to read: Success"). Signed-off-by: Jeff King --- I am not convinced this is the right solution. Specifically: - there are a few other calls to ferror. Maybe they should be converted, too, which implies that perhaps there is a better idiom for checking this. - I have no idea how portable this is. Do all stdio implementations fail to restart on signal? Do they all set ferror and have errno == 0 (I would have expected EINTR, or at the very least a 0-read without ferror set)? But it works for me (Linux, glibc 2.7). tig.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tig.c b/tig.c index 6b111e4..8362ecf 100644 --- a/tig.c +++ b/tig.c @@ -2392,7 +2392,7 @@ update_view(struct view *view) update_view_title(view); check_pipe: - if (ferror(view->pipe)) { + if (ferror(view->pipe) && errno != 0) { report("Failed to read: %s", strerror(errno)); end_update(view, TRUE); -- 1.6.0.98.g0d3cc ``` ## Jonas Fonseca, 2008-08-22 10:10 Subject: Re: [tig PATCH] continue updates when pipe read has errno "Success" Message-ID: <2c6b72b30808220310v1083e860tef9fd6efa57767e3@mail.gmail.com> URL: https://gitlist.dev/e/2c6b72b30808220310v1083e860tef9fd6efa57767e3%40mail.gmail.com In-Reply-To: <20080821014043.GA14452@coredump.intra.peff.net> ``` On Thu, Aug 21, 2008 at 03:40, Jeff King wrote: > When we are reading from a pipe and receive a signal, our > read call fails and ferror() returns true. The current > behavior is to call end_update and report failure. However, > we can detect this situation by checking that errno is set > to success and continue the reading process. Thanks for the fix/workaround! > I am not convinced this is the right solution. Specifically: > > - there are a few other calls to ferror. Maybe they should be > converted, too, which implies that perhaps there is a better idiom > for checking this. Well, perhaps something like this can work around the issue for tig-0.12: bool check_ferror(FILE *file) { return ferror(file) && errno != 0; } For a possible "better" fix, I have been working on moving tig to use the run-command.[ch] code from git, which means that ferror() will no longer be needed. It is still not ready but looks promising. > - I have no idea how portable this is. Do all stdio implementations > fail to restart on signal? Do they all set ferror and have errno == > 0 (I would have expected EINTR, or at the very least a 0-read > without ferror set)? > > But it works for me (Linux, glibc 2.7). I have tested it on FreeBSD which doesn't seem to have this problem with ferror(). Anyway, the workaround doesn't break anything so applied. -- Jonas Fonseca ``` ## Jeff King, 2008-08-22 15:59 Subject: Re: [tig PATCH] continue updates when pipe read has errno "Success" Message-ID: <20080822155914.GB5280@coredump.intra.peff.net> URL: https://gitlist.dev/e/20080822155914.GB5280%40coredump.intra.peff.net In-Reply-To: <2c6b72b30808220310v1083e860tef9fd6efa57767e3@mail.gmail.com> ``` On Fri, Aug 22, 2008 at 12:10:35PM +0200, Jonas Fonseca wrote: > Thanks for the fix/workaround! Thank you for making tig. ;) > For a possible "better" fix, I have been working on moving tig to use > the run-command.[ch] code from git, which means that ferror() will no > longer be needed. It is still not ready but looks promising. I think that would be much cleaner, as the semantics of system calls and signals tend to be better defined. -Peff ```