From: Sylvain Rabot <sylvain@abstraction.fr>
To: Jakub Narebski <jnareb@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 3/3] gitweb: remove test when closing file descriptor
Date: Thu, 16 Dec 2010 23:37:00 +0100 [thread overview]
Message-ID: <1292539020.2511.6.camel@kheops> (raw)
In-Reply-To: <m3pqu4lx6n.fsf@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2599 bytes --]
On Thu, 2010-12-16 at 14:30 -0800, Jakub Narebski wrote:
> Sylvain Rabot <sylvain@abstraction.fr> writes:
>
> > it happens that closing file descriptor fails whereas
> > the blob is perfectly readable.
> >
> > Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>
> > ---
> > gitweb/gitweb.perl | 3 +--
> > 1 files changed, 1 insertions(+), 2 deletions(-)
> >
> > diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> > index 9398475..9a885b1 100755
> > --- a/gitweb/gitweb.perl
> > +++ b/gitweb/gitweb.perl
> > @@ -3450,8 +3450,7 @@ sub run_highlighter {
> > my ($fd, $highlight, $syntax) = @_;
> > return $fd unless ($highlight && defined $syntax);
> >
> > - close $fd
> > - or die_error(404, "Reading blob failed");
> > + close $fd;
>
> Actually what I think happens is the following. "close $fh" cannot
> usually fail, unless (`perldoc -f close`):
>
> If the file handle came from a piped open, "close" will additionally
> return false if one of the other system calls involved fails, or if the
> program exits with non-zero status. (If the only problem was that the
> program exited non-zero, $! will be set to 0.) Closing a pipe also waits
> for the process executing on the pipe to complete, in case you want to
> look at the output of the pipe afterwards, and implicitly puts the exit
> status value of that command into $?.
>
> Prematurely closing the read end of a pipe (i.e. before the process writ-
> ing to it at the other end has closed it) will result in a SIGPIPE being
> delivered to the writer. If the other end can't handle that, be sure to
> read all the data before closing the pipe.
>
> In this place we close read end of pipe after at most reading a few
> bytes (what -T test does), so what might happen is that writer got
> SIGPIPE and "failed". But we are not interested in this, so we can
> safely ignore return from 'close'.
>
> I think that some from above explanation should make it to commit
> message.
Thanks for explaining it, I did not have any idea why it was failing.
Can I use your explanation as commit message ?
>
> > open $fd, quote_command(git_cmd(), "cat-file", "blob", $hash)." | ".
> > quote_command($highlight_bin).
> > " --xhtml --fragment --syntax $syntax |"
>
> P.S. A better solution would be to redirect opened $fd to highlighter,
> instead of closing and reopening a pipe... but I'm not sure how it
> could be implemented.
I don't know either.
>
--
Sylvain Rabot <sylvain@abstraction.fr>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2010-12-16 22:37 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-16 21:43 [PATCH 0/3] minor gitweb modifications Sylvain Rabot
2010-12-16 21:43 ` [PATCH 1/3] gitweb: add extensions to highlight feature Sylvain Rabot
2010-12-16 22:22 ` Jakub Narebski
2010-12-16 22:33 ` Sylvain Rabot
2010-12-17 11:17 ` Jakub Narebski
2010-12-16 21:43 ` [PATCH 2/3] gitweb: decorate a bit more remotes Sylvain Rabot
2010-12-16 22:23 ` Jakub Narebski
2010-12-20 12:04 ` Drew Northup
2010-12-16 21:43 ` [PATCH 3/3] gitweb: remove test when closing file descriptor Sylvain Rabot
2010-12-16 22:30 ` Jakub Narebski
2010-12-16 22:37 ` Sylvain Rabot [this message]
2010-11-16 23:02 ` Jakub Narebski
-- strict thread matches above, loose matches on Subject: below --
2010-12-20 19:01 [PATCH 0/3 v2] minor gitweb modifications Sylvain Rabot
2010-12-20 19:01 ` [PATCH 3/3] gitweb: remove test when closing file descriptor Sylvain Rabot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1292539020.2511.6.camel@kheops \
--to=sylvain@abstraction.fr \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).