Re: [RFC PATCHv2 04/10] gitweb: Use Cache::Cache compatibile (get, set) output caching

From: Petr Baudis <pasky@suse.cz>
Date: Feb 10, 2010, 01:23 UTC
Message-ID: <20100210012343.GS9553@machine.or.cz>
In-Reply-To: <201002100212.26157.jnareb@gmail.com>

On Wed, Feb 10, 2010 at 02:12:24AM +0100, Jakub Narebski wrote:

Show 19 quoted lines

> On Tue, 9 Feb 2010 at 11:30 +0100, Jakub Narebski wrote:
> 
> > The cache_fetch subroutine captures output (from STDOUT only, as
> > STDERR is usually logged) using either ->push_layer()/->pop_layer()
> > from PerlIO::Util submodule (if it is available), or by setting and
> > restoring *STDOUT.  Note that only the former could be tested reliably
> > to be reliable in t9503 test!
> 
> Scratch that, I have just checked that (at least for Apache + mod_cgi,
> but I don't think that it matters) the latter solution, with setting
> and restoring *STDOUT doesn't work: I would get data in cache (so it
> can be restored later), but instead of output I would get Internal Server
> Error ("The server encountered an internal error or misconfiguration and
> was unable to complete your request.") without even a hint what the
> problem was.  Sprinkling "die ...: $!" didn't help to catch this error:
> I suspect that the problem is with capturing.
> 
> So we either would have to live with non-core PerlIO::Util or (pure Perl)
> Capture::Tiny, or do the 'print -> print $out' patch...

All the magic methods seem to be troublesome, but in that case I'd really prefer a level of indirection instead of filehandle - as is, 'print (...) -> output (...)' ins. of 'print (...) -> print $out (...)' (or whatever). That should be really flexible and completely futureproof, and I don't think the level of indirection would incur any measurable overhead, would it?

-- 
				Petr "Pasky" Baudis
If you can't see the value in jet powered ants you should turn in
your nerd card. -- Dunbal (464142)