Mod_perl child_init calls not returning values

[Thomas Berezansky]

Apparently mod_perl expects (but disregards) return values on child_init calls.

We don't tend to return anything....so the branch below makes things return Apache2::Const::OK instead.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/apache_child_init_returns

[Lebbeous Fogle-Weekley (lebbeous)]

Thomas,

Without this patch, are there any symptoms of Apache's discontent? Just wondering what let to this or what problem behavior, if any, we can expect to go away.

[Jason Stephenson (jstephenson)]

Lebbeous,

While there are no obvious symptoms Apache handler init methods are expected to return a value to indicate success or failure. Perl handlers are not explicitly given a pass.

Best practice would be to include the branch.

Jason

[Lebbeous Fogle-Weekley (lebbeous)]

mod_perl itself will return OK to Apache for us when the scalar return value of child_init() is undef. See

src/modules/perl/modperl_callback.c line 112 as of r1420856 in mod_perl's SVN repo.

Granted this is mainly meant to support a thing that replaces exit() in order to ease the shoehorning of Perl scripts that call exit() into mod_perl environments, but it has the same effect if we just call a bare 'return' in handlers. Some of our child_init handlers implicitly returned 1 or other values as side-effects of the final statements in them, but those pass through unchanged to Apache, which doesn't do anything with them.

This seems like gold plating. However, if it doesn't hurt anything, and if the work has already been done to be more "correct" along the lines of recommendations like the one here, http://modperlbook.org/html/25-2-1-3-PerlChildInitHandler.html , I'll merge it just to get it off the list of open bugs.

Merged to master and backported through rel_2_2.