William A. Rowe, Jr. wrote: > At 07:02 PM 7/9/2003, Geoffrey Young wrote: > > >> William A. Rowe, Jr. wrote: >> >>> It seems like the API for ap_mpm_query would be simpler to >>> follow, just extended to run outside-of-apache. >> >> probably, and it would certainly be safer than checking -V >> output. the issue I see with this is that thus far Apache-Test is >> pure perl, so it seems overkill to get into the C API and XS for >> just for one small feature. unless I'm missing something, that >> is :) > > > You are :-) It sounds like httpd -V should grow some ap_mpm_query > output for the user to know what sorts of flags are toggled for > that build of httpd?
ok, I see - something similar to apxs -q? that would definitely be useful.
I'm no vacation for the next two weeks, but when I get back I'll take a stab at the interface and see what I can do (if nobody beats me to it).
in either case, I still think have_apache_mpm() is a decent API for Apache-Test, no matter how it's implemented behind the scenes. does it make sense to get that in first as I last proposed then change the implementation later? I guess the other option is to dump have_apache_mpm() in favor of a more generic query_apache() (or have both :)
thanks for the feedback.
...
> APR_HAS_THREADS only tells you if APR was built to support > threading. I always build my core against the threaded APR so that > all of the entry points for a threaded module are available. If > the module is smart enough to check ap_mpm_query for threading (as > mod_auth_digest and mod_ssl do) then they can skip all of the > interlock calls when running under prefork (even though they were > compiled against a threaded APR.) > > That same module can now be loaded under prefork and worker.
excellent. thanks again.
--Geoff
