With anon-subs we need cover three cases of anon-subs:
$r->push_handlers(PerlTransHandler => sub { .... });
$r->push_handlers(PerlTransHandler => eval 'sub { .... }');
PerlTransHandler 'sub { ... }' # httpd.confStore the CODE refs in a special hash %ModPerl::__Subs::subs and store the key names in the mod_perl struct. It should transparently work with threads and resolves the problem with anon-subs.
If we have a situation where an interpreter that wants to run an anon-sub can't find the key entry (if the interpreter has compiled it and registered with mod_perl), we just croak explaining that in this special case (and most people won't ever get here) one needs to preload such modules at the server startup.
The only tricky parts is how to name the keys. We can't just increment some counter like Symbol.pm does, since it's quite possible that two interpreters will register different callbacks with the same key and there will be a big trouble.
One solution is to generate the keys on the C side using an internal counter. The only minus is that we will need to handle locking of that resource which should be global to the process.
Another solution is to somehow include __FILE__:__LINE__ to uniquely identify the anon-subs, but that will probably be hard to do.
Ideas?
meanwhile I'm trying to see whether this idea of %ModPerl::__Subs::subs will work.
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
