gitweb/lib - Regenerate (refresh) cache in background
commit3d88e50189e0e28911eaddec08033f6a133a223e
authorJakub Narebski <jnareb@gmail.com>
Sun, 5 Dec 2010 23:01:09 +0000 (6 00:01 +0100)
committerJakub Narebski <jnareb@gmail.com>
Sun, 5 Dec 2010 23:01:09 +0000 (6 00:01 +0100)
treee4bbc7bfa7ced787c28e7e5d5573cccb3ed7847e
parent3089c00fc30e89469f4cf3dd6927ebfc5c4a1ba7
gitweb/lib - Regenerate (refresh) cache in background

This commit removes asymmetry in serving stale data (if stale data exists)
when regenerating cache in GitwebCache::FileCacheWithLocking.  The process
that acquired exclusive (writers) lock, and is therefore selected to
be the one that (re)generates data to fill the cache, can now generate
data in background, while serving stale data.

Those background processes are daemonized, i.e. detached from the main
process (the one returning data or stale data).  Otherwise there might be a
problem when gitweb is running as (part of) long-lived process, for example
from mod_perl or from FastCGI: it would leave unreaped children as zombies
(entries in process table).  We don't want to wait for background process,
and we can't set $SIG{CHLD} to 'IGNORE' in gitweb to automatically reap
child processes, because this interferes with using
  open my $fd, '-|', git_cmd(), 'param', ...
    or die_error(...)
  # read from <$fd>
  close $fd
    or die_error(...)
In the above code "close" for magic "-|" open calls waitpid...  and we
would would die with "No child processes".  Removing 'or die' would
possibly remove ability to react to other errors.

This feature can be enabled or disabled on demand via 'background_cache'
cache parameter.  It is turned on by default.

The t9503 test got updated to test both case with background generation
enabled and case with background generation disabled.

Inspired-by-code-by: John 'Warthog9' Hawley <warthog9@kernel.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
gitweb/gitweb.perl
gitweb/lib/GitwebCache/FileCacheWithLocking.pm
t/t9503/test_cache_interface.pl