All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Peter Vereshagin <peter@vereshagin.org>
Cc: Petr Baudis <pasky@suse.cz>, Eric Wong <normalperson@yhbt.net>,
	git@vger.kernel.org, Sam Vilain <sam.vilain@catalyst.net.nz>,
	Juan Jose Comellas <juanjo@comellas.org>,
	John Goerzen <jgoerzen@complete.org>
Subject: Re: [PATCH 0/2] gitweb: Add support for running gitweb as FastCGI script
Date: Tue, 11 May 2010 12:58:50 +0200	[thread overview]
Message-ID: <201005111258.53388.jnareb@gmail.com> (raw)
In-Reply-To: <20100511062415.GA5220@screwed.box>

On Tue, 11 May 2010, Peter Vereshagin <peter@vereshagin.org> wrote:
> 2010/05/10 17:29:03 +0200 Jakub Narebski <jnareb@gmail.com> => To Peter Vereshagin :
> > On Mon, 10 May 2010, Peter Vereshagin wrote:

> > >  ## ======================================================================
> > >  ## action links
> > > @@ -3371,7 +3371,7 @@ sub die_error {
> > 
> > I have added my guess of in which subroutine this code is above.

[...]
> > >         git_footer_html();
> > > -       exit;
> > > +#              exit;
> > >  }
> > 
> > Err... and gitweb works correctly with this change?  This 'exit' was
> > required for die_error to function like 'die' in that it finishes
> > serving request, and should not continue subroutine it was called
> > from.
> 
> Does at least on 'non-existent diff' page:
> 
> http://gitweb.vereshagin.org/fcgiproxy/commitdiff/abcd

Hmmm... strange that it works.
 
> > I have changed this 'exit' to non-local goto to toplevel.  It could be
> > done instead by redefining 'exit' subroutine, like shown below, but I
> > feel that would be hacky if you can change gitweb code (it is not
> > black box you should not touch).
> 
> Right, one shouldn't ever redefine perl built-in functions. I did only because
> of no other way to 'get things working'

Why not?  For example CGI::Carp redefines 'die' to log errors.

  BEGIN { 
    require Carp; 
    *CORE::GLOBAL::die = \&CGI::Carp::die;
  }

Sub::Uplevel and Test::Exception redefines 'caller' (perhaps locally).
CGI::Compile redefines 'exit':

  our $USE_REAL_EXIT;
  BEGIN {
      $USE_REAL_EXIT = 1;
      *CORE::GLOBAL::exit = sub (;$) {
          my $exit_code = shift;

          CORE::exit(defined $exit_code ? $exit_code : 0) if $USE_REAL_EXIT;

          die [ "EXIT\n", $exit_code || 0 ]
      };
  }


> > This is quite nice idea to replace 'exit' by subroutine that does
> > non-local jump to outside of application, at the end of request loop.
> > Such "monkey patching" is the only solution if you can't or shouldn't
> > modify application code (like FCGI::Spawn being generic solution).
> 
> Yes, this is quick-n-dirty to apply for those monkeys who are just busy to care
> about re-writing CGI apps.

Errr... "monkey patching" is the name of technique of extending and
modifying runtime code in dynamic languages, see

  http://en.wikipedia.org/wiki/Monkey_patch
 
Although I am not entirely sure if I correctly applied this name to
described (used) techique.

> > Here
> > 
> >    $spawn->{'callout'} = sub {
> >    	my $cgi_app = shift;
> >    	do $cgi_app;
> > 
> >     # this is needed for sane error handling
> >     die "Couldn't parse $cgi_app: $@" if $@;
> > 
> >    CALLED_OUT: 
> >    };
> 
> In a forked application, die() is a PITA on any reasonable load. It makes the
> CoW-shared memory to be copied into separate area and being marked as unusable
> before the process is dead. This is the only case I saw load averages on the
> servers valued as crazy ~700.
>
> So just exit there, not die. 

Well, it might be 'exit' not 'die', but you really, really need to check
if there were problems parsing file.  Otheriwse you can get error
messages somewhere further on that doesn't absolutely make sense.  

I know this from painful experience of trying to find bug in a
test... when the error was in parsing file in 'do $file;'.

> By far, die can not be redefined the same way as I propose for exit in
> FCGI::Spawn.

It can't?  CGI::Carp redefines 'die'.
 
> > > [...] FCGI::Spawn is just for some different task: to put several
> > > (wish to say: any CGI app) applications inside the same fork()ed
> > > processes. [...]
> > 
> > Hmmm... is FCGI::Spawn really needed, or can it be replaced by simple
> > PSGI wrapper using either Plack::App::CGIBin, 
> > 
> >   use Plack::App::CGIBin;
> >   use Plack::Builder;
> > 
> >   my $app = Plack::App::CGIBin->new(root => "/path/to/cgi-bin")->to_app;
> >   builder {
> >         mount "/cgi-bin" => $app;
> >   };
> 
> You use the predefined paths here on initialization. FCGI::Spawn knows about
> the CGI application's path at the right moment it takes the request.

No, you need to provide only *root*, i.e. where Perl CGI applications
are, so that e.g. accessing 'http://0:5000/cgi-bin/foo/bar.cgi' would
run PSGI-ized (via CGI::Emulate::PSGI) '/path/to/cgi-bin/foo/bar.cgi'
application.

You don't need to mount it at "/cgi-bin", you can just

  builder {
        $app;
  }

or even without it ($app should be the last expression).


Or did you mean here something like mod_rewrite, or
Plack::Middleware::Rewrite?

[...]  
> > Gitweb doesn't use no POST requests: it is read-only web repository
> > browser... well, except for the 'show_ctags' action.
> 
> Tag cloud? Is there an example of usable tag cloud on any public gitweb out
> there?

Tag cloud are optional feature in stock gitweb, named 'ctag' in %feature
hash.  It is disabled by default.  If I understand correctly POST is
used here to populate which tags one wants to use... but perhaps GET
request would be enough here (at the cost of less readable URL).

See http://repo.or.cz for example usage of this feature.

-- 
Jakub Narebski
Poland

  parent reply	other threads:[~2010-05-11 10:59 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-07 12:54 [PATCH 0/2] gitweb: Add support for running gitweb as FastCGI script Jakub Narebski
2010-05-07 12:54 ` [PATCH/RFC 1/2] gitweb: Put all per-connection code in run() subroutine Jakub Narebski
2010-05-07 12:54 ` [RFC/PATCH 2/2] gitweb: Add support for FastCGI, using CGI::Fast Jakub Narebski
2010-05-08  7:59   ` [RFC/PATCHv2 " Jakub Narebski
2010-05-08 22:41 ` [PATCH 0/2] gitweb: Add support for running gitweb as FastCGI script Jakub Narebski
2010-05-09  9:31   ` Eric Wong
2010-05-09 11:48     ` Ævar Arnfjörð Bjarmason
2010-05-09 12:39     ` Jakub Narebski
2010-05-09 16:47       ` Peter Vereshagin
2010-05-09 18:18         ` Jakub Narebski
2010-05-10  7:13           ` Peter Vereshagin
2010-05-10 15:29             ` Jakub Narebski
2010-05-11  6:24               ` Peter Vereshagin
2010-05-11  8:35                 ` Petr Baudis
2010-05-11 10:58                 ` Jakub Narebski [this message]
2010-05-11 12:09                   ` Peter Vereshagin
2010-05-11 13:51                     ` Jakub Narebski
2010-05-13 13:10                       ` Peter Vereshagin
2010-05-13 17:13                         ` Ævar Arnfjörð Bjarmason
2010-05-14 15:58                           ` Peter Vereshagin
2010-05-14 10:53                         ` Jakub Narebski
2010-05-14 15:36                           ` Peter Vereshagin
2010-05-14 17:58                             ` Jakub Narebski
2010-05-14 18:43                               ` Jakub Narebski
2010-05-15 10:06                               ` Peter Vereshagin
2010-05-15 13:58                                 ` Jakub Narebski
2010-05-16 10:15                                   ` Peter Vereshagin
2010-05-18  1:06                                     ` Jakub Narebski
2010-05-16 10:26                                   ` Petr Baudis
2010-05-15 11:51                           ` Petr Baudis

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=201005111258.53388.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jgoerzen@complete.org \
    --cc=juanjo@comellas.org \
    --cc=normalperson@yhbt.net \
    --cc=pasky@suse.cz \
    --cc=peter@vereshagin.org \
    --cc=sam.vilain@catalyst.net.nz \
    /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.