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: Fri, 14 May 2010 19:58:15 +0200 [thread overview]
Message-ID: <201005141958.16469.jnareb@gmail.com> (raw)
In-Reply-To: <20100514153636.GB17443@screwed.box>
On Fri, 14 May 2010, Peter Vereshagin wrote:
> 2010/05/14 12:53:42 +0200 Jakub Narebski <jnareb@gmail•com> => To Peter Vereshagin :
>> legitimate uses of 'goto' that make the program simpler to understand,
>> and not harder,... among those is handling exceptions.
>
> so did you change the exception-related exit()s on your patch to the
> "last" ?
Yes, die_error(), which had "exit" that got replaced by non-local "goto"
is exception-related subroutine.
>> The problem is that "do <file>;" is similar to "eval `cat <file>`;"
>> (except that it's more efficient and concise), it that it silences
>> parsing errors. From `perldoc -f do`:
>>
>> If "do" cannot read the file, it returns undef and sets $! to the error.
>> If "do" can read the file but cannot compile it, it returns undef and sets
>> an error message in $@. If the file is successfully compiled, "do"
>> returns the value of the last expression evaluated.
>>
>>> And yes, since it's about development but not production use, die is just fine
>>> in the inclusion code like this:
>>>
>>> eval( 'use Module;' ); die $@ if $@;
>>
>> Wrong!
>
> The problem was you can't see the reason of the inclusion-via-do()
> parsing failure.
You don't see the parsing failure because "do <file>;" functions like
"eval", which traps exceptions. You will see consequences of parsing
failure (like not defined subroutine).
> But you may see it with "use warnings;" right?
"use warnings;" pragma doesn't help, because of the 'trapping
exceptions' part. That is why "require <file>" is recommended over
"do <file>".
>>> as always, require() can do the trick, not to mention usual
>>>
>>> use Module;
>>>
>>> This all will cause die() when it's necessary as only the application developer
>>> knows how strict is the dependence on the Module. In some cases, application
>>> can work without some Module but it's just better with it.
>>
>> First, both "use Module;" and "require Module;" (and "require '<file>';")
>> do automatic error checking and raise an exception if there is problem.
>
> for web applications, half of exceptions or more are generated when the user
> isn't the develioper.
> Notifications() via the logs are just enough and more than it: should be the
> prefered way of exceptions' notifications in a production.
> Why worry about return code then?
Checking $@ after "do <file>" would cover the situation where there were
parsing errors, but wouldn't cover situation where file was not found,
or there was error in executing code (but parsing was O.K.).
>> Second, "use Module <LIST>;" is equivalent to
>> BEGIN { require Module; import Module <LIST>; }
>> and therefore it doesn't make sense to use it for conditional inclusion.
>
> eval() is used there.
It's the fact that "use Module" uses BEGIN block that is incompatibile
with *conditional* using it from eval.
>>>> PSGI is interface, Plack is reference implementation. You can run PSGI
>>>> app on any supported web server; this includes running PSGI apps on
>>>> FastCGI.
>>>
>>> Existing problem FCGI::Spawn for is not the PSGI applications to be run as a
>>> FastCGI, but the bunch of existing CGI.pm applications (even gitorious) need
>>> to be more effective with the widest-spread protocol FastCGI. Best without any
>>> patching of the application, deployed the same simple way as with apache's cgi
>>> implementation.
>>
>> Gitorious is in Ruby, therefore is not a CGI.pm application, as it is
>> not even in Perl.
>
> It was Girocco you mentioned earlier
Girocco is shell scripts, not Perl either, see
http://repo.or.cz/w/girocco.git/tree
>> By using Plack::App::CGIBin you can load CGI scripts from a directory
>> and convert them into a <persistent> PSGI application. You can use
>
> Such a conversion is more than a compilation? Does it mean converted CGI app
> should be stored before to become a persistent application?
This convertion is
a.) compiling CGI file into subroutine (taking care of things like DATA
filehandle) using CGI::Compile
b.) converting between CGI interface and PSGI interface, using
CGI::Emulate::PSGI
CGI::Compile manpage includes this example:
use CGI::Emulate::PSGI;
use CGI::Compile;
my $cgi_script = "/path/to/foo.cgi";
my $sub = CGI::Compile->compile($cgi_script);
my $app = CGI::Emulate::PSGI->handler($sub);
# $app is a PSGI application
>> Plack::App::WrapCGI to convert single CGI script into PSGI application.
>> You can use Plack::Buuilder's domain specific language to join (map)
>> together a bunch of PSGI applications (in different paths) in a single
>> app (via Plack::App::URLMap).
>
> And can the same process of that application server run for the several
> applications depending on the FastCGI request?
Yes, it can. Depending on request it would run appropriate
CGI-converted-to-PSGI application.
I am not sure how Plack::App::CGIBin works internally; it migh cimpile
all CGI applications upfront; but it might not.
>> You can then run PSGI application (for example the PSGI app which loads
>> CGI apps via Plack::App::CGIBin) on any supported web server, which
>> includes FCGI (FastCGI).
--
Jakub Narebski
Poland
next prev parent reply other threads:[~2010-05-14 17:58 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
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 [this message]
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=201005141958.16469.jnareb@gmail.com \
--to=jnareb@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=jgoerzen@complete$(echo .)org \
--cc=juanjo@comellas$(echo .)org \
--cc=normalperson@yhbt$(echo .)net \
--cc=pasky@suse$(echo .)cz \
--cc=peter@vereshagin$(echo .)org \
--cc=sam.vilain@catalyst$(echo .)net.nz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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