All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.