Something like that (again just an idea). Perhaps we should really create a struct:
typedef enum { VOID, RUN_FIRST, RUN_ALL } modperl_hook_run_mode_e
struct modperl_hook_t { const char *desc; modperl_hook_run_mode_e run_mode; };
and now we can kill all the modperl_handler_desc_ functions and just return this struct from modperl_hooks.c. Later on we might fold in more information. Do you think anything else should be added there?
would those MP_ constants be helpful, such as MP_HANDLER_TYPE_PER_DIR and MP_HEADER_PARSER_HANDLER? it's hard to tell without working on an implementation.
You mean using define constants, instead of enums? Or do you suggest to move defines into this struct?
Or is it considered a bad practice to create a struct for a static data that never changes?
I have no idea, not being a real C guy.
I suppose arrays and structs are similar beasts, so if we can have an array we can have a struct. The idea is to make things more self-contained, currently we have too many things spread around.
The drawback of using dynamic types in the performance sense, is that they won't be mapped to static text pages in memory, but will use heap memory. But since no child process will actually modify those, they will be shared as long as they end up on the same page with other dynamically allocated vars which don't change.
if we proceed this way it's probably going to take me a while to come up with another patch, since I'll need to do some reading first to fill in the gaps in my C :)
In that case, go with your very first (not the second) solution: pass the run_all variable as an argument and define three constants RUN_ALL/RUN_FIRST/VOID and act accordingly. Later on we can revamp it without changing the user behavior.
__________________________________________________________________ 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]
