Currently filters are registered via 4 names and then the same name is re-used
to push one to many mod_perl filters. The problem with this implementation is
that we can't remove filters. And I think we should be able to remove filters
that were added dynamically. This requires a re-design of the filters
registration/addition mechanism, where instead of the four names we use the
real name of the filter should be used when registering/adding it.
This is doable with filters registered by using their sub name or name
resolved from a coderef, as long as it's not an anonymous coderef. How can we
handle this for anonymous coderefs? If I understand correctly, there are two
problems with anonymous coderefs:
1. two different interpreters may give two different functions the same CODE
reference address, so we can's just use the CODE address as a function name.
2. the original interpreter must be stored and used when running it, but what
happens to the interpreter that was selected to run that particular phase? The
original interpreter might be from a different pool, and it's a big pandora box.
I guess these are the same reasons why we still have not implemented the
resolving of anonymous coderefs in modperl_mgv_name_from_sv. So how can we
approach this issue?
Another issue is with add filter functions (e.g., $r->add_input_filter()). The
file todo/filters.txt (which seems to be quite outdated) suggest to pass an
optional $ctx:
$r->add_output_filter($name, $ctx)
Though I think it's problematic. What happens if $ctx is created by one
interpreter, but then the filter run by another one? I know that we can store
the pointer to the original interpreter that has created $ctx, but once we run
the filter we will have to set that interpreter as the current, ignoring the
interpreter that was selected to run the filter handler. Do you see the
problem here? It's the same issue as #2 I've listed above.
__________________________________________________________________
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]
