You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Geoffrey Young <ge...@modperlcookbook.org> on 2004/02/29 06:54:08 UTC
Re: dynamic request hook ordering (take 2)
here's another pass that incorporates the suggestions thus far. comments on
the global foo appreciated. the tests I posted before are still valid at
this point.
--Geoff
Re: dynamic request hook ordering (take 2)
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
>><IfModule mpm_winnt.c>
>> ThreadsPerChild 50
>> MaxRequestsPerChild 0
>></IfModule>
>>
>>The standard mp2 testsuite now passes all tests successful.
>
>
> I forgot to mention - I've also found lately that raising
> this limit is necessary.
Any idea why? 50 threads is not enough to run the tests, when with prefork
only 2 workers are needed at most. Do we have some threads leak?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: dynamic request hook ordering (take 2)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> I just got hold of VC++ 6.0 and was waiting for 2.0.49 to be release before
> trying to compile everything again. but now that it's out I'll give it all
> another whirl with the more recent version and see how it goes.
>
> one of the things on my hit list is post-connect being called 4x instead of
> 2x like on unix, since that seems to be a major difference between the
> platforms. but no sense guessing...
well, I think I'm about to give up. I've determined that the problem isn't
in my logic but rather in some other interaction between httpd and mod_perl.
the attached test case proves it to me - the hook order logic
(mod_hook_order.c) runs just fine as it's own post_config handler, but when
the same block is copied into mod_perl's post_config handler I see the
familiar invalid handle errors.
so, I'm probably going to drop it as I'm out of ideas. thanks all for
taking the time to help me debug, though.
--Geoff
Re: dynamic request hook ordering (take 2)
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>>>one of the things on my hit list is post-connect being called 4x
>>>instead of
>>>2x like on unix, since that seems to be a major difference between the
>>>platforms. but no sense guessing...
>>
>>
>>Earlier Bill posted a trick how to avoid this situation (i.e.
>>controlling how many times a certain code is called).
>>
>
>
> yeah, that's what I was planning on implementing to see if it made a difference.
though i'd suggest to use the abstracted API that I've posted to httpd-dev. So
we can just check the flag and next expose it to users so that they can
control their own post-config and open-logs phases to make sure that they will
run only once. That's what mp1 had for $Starting and $Restarting, but i'd
suggest to revise that API and use a counter instead, since as we can see some
mpms have it more than 2 times.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: dynamic request hook ordering (take 2)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> one of the things on my hit list is post-connect being called 4x
>> instead of
>> 2x like on unix, since that seems to be a major difference between the
>> platforms. but no sense guessing...
>
>
> Earlier Bill posted a trick how to avoid this situation (i.e.
> controlling how many times a certain code is called).
>
yeah, that's what I was planning on implementing to see if it made a difference.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: dynamic request hook ordering (take 2)
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>Well, now that 2.0.49 is out I was finally able to try the latest Apache
>>stuff with your hook ordering patch (I still don't know to build CVS
>>Apache 2 on Win32), but unfortunately it still doesn't work. The usual
>>invalid handle error, same as before.
>
>
> thanks for trying :)
>
> I just got hold of VC++ 6.0 and was waiting for 2.0.49 to be release before
> trying to compile everything again. but now that it's out I'll give it all
> another whirl with the more recent version and see how it goes.
>
> one of the things on my hit list is post-connect being called 4x instead of
> 2x like on unix, since that seems to be a major difference between the
> platforms. but no sense guessing...
Earlier Bill posted a trick how to avoid this situation (i.e. controlling how
many times a certain code is called).
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: dynamic request hook ordering (take 2)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Well, now that 2.0.49 is out I was finally able to try the latest Apache
> stuff with your hook ordering patch (I still don't know to build CVS
> Apache 2 on Win32), but unfortunately it still doesn't work. The usual
> invalid handle error, same as before.
thanks for trying :)
I just got hold of VC++ 6.0 and was waiting for 2.0.49 to be release before
trying to compile everything again. but now that it's out I'll give it all
another whirl with the more recent version and see how it goes.
one of the things on my hit list is post-connect being called 4x instead of
2x like on unix, since that seems to be a major difference between the
platforms. but no sense guessing...
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: dynamic request hook ordering (take 2)
Posted by Steve Hay <st...@uk.radan.com>.
Steve Hay wrote:
> Geoffrey Young wrote:
>
>> so cool, we've isolated the "I can't start problem" to something in
>> apr_hook_sort_all().
>>
>> so I guess the place to start looking is apr_hooks.c. I'll take a
>> look at
>> it some more and throw in some debugging statement to see if anything
>> jumps
>> out at me. one thing I've done already is to add some more details
>> to the
>> core sort (attached).
>>
> I applied your hooks diff to the "hook_order-final2.patch" version and
> tried to start up the server in one-process mode with "-D
> ReallyLast". I also turned on most MOD_PERL_TRACE flags too if that
> helps any. Attached is the error_log and console output.
>
> I noticed that your hooks diff was clearly produced against a later
> version of apr_hooks.c than I have (2.0.48). Presumably you're using
> CVS Apache2? I wonder if that makes any difference.
Well, now that 2.0.49 is out I was finally able to try the latest Apache
stuff with your hook ordering patch (I still don't know to build CVS
Apache 2 on Win32), but unfortunately it still doesn't work. The usual
invalid handle error, same as before.
Just ruling out another possibility :(
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: dynamic request hook ordering (take 2)
Posted by Steve Hay <st...@uk.radan.com>.
Geoffrey Young wrote:
>>>the only thing I could suggest at this point is to comment out the
>>>apr_hook_sort_all() call in modperl_apache_resort_hooks() to see if there
>>>isn't something about that function (or calling it) that is mucking up the
>>>works. what that would leave is the altering of the hook structure but (in
>>>theory) have no real effect since the hook order is the same as it was going in.
>>>
>>>
>>>
>>That makes a difference: The original test suite now gets as far as the
>>second test (-DReallyLast)
>>
>>
>
>
>
>>There's nothing interesting in the error_log, and the test suite is
>>aborted there. I assume the failure is simply because what's being
>>tested for hasn't actually been done this time.
>>
>>
>
>right - the test should fail because the order hasn't actually changed here.
> but it ran.
>
>so cool, we've isolated the "I can't start problem" to something in
>apr_hook_sort_all().
>
>so I guess the place to start looking is apr_hooks.c. I'll take a look at
>it some more and throw in some debugging statement to see if anything jumps
>out at me. one thing I've done already is to add some more details to the
>core sort (attached).
>
I applied your hooks diff to the "hook_order-final2.patch" version and
tried to start up the server in one-process mode with "-D ReallyLast".
I also turned on most MOD_PERL_TRACE flags too if that helps any.
Attached is the error_log and console output.
I noticed that your hooks diff was clearly produced against a later
version of apr_hooks.c than I have (2.0.48). Presumably you're using
CVS Apache2? I wonder if that makes any difference.
I tried to upgrade my Apache2 to the latest CVS, but couldn't. I got
all the latest httpd-2.0, apr, apr-iconv and apr-util code from
cvs.apache.org, but none of it builds on Win32! Those sources all
correspond to the httpd-2.X.YY.tar.gz distributions that you guys use on
UNIX, but those distributions don't build on Win32. We have to use
httpd-2.X.YY-win32-src.zip on Win32 instead. The Win32 ZIP file
contains extra *.mak and *.dep files needed to build stuff. I tried
copying the extra files from 2.0.48 into my CVS source tree, but I can't
get the damn thing to build -- the makefiles all clearly need updating :(
Anyone know where to get the latest Win32 makefiles etc for Apache2 from?
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: dynamic request hook ordering (take 2)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>>ok. I don't suppose that sleeping between startups makes a difference?
>>
>
> Sleeping between what? One test /on its own/ doesn't work!
yes, I realized after I sent it that you already found the problem has
nothing to do with stopping or starting. oops :)
>>the only thing I could suggest at this point is to comment out the
>>apr_hook_sort_all() call in modperl_apache_resort_hooks() to see if there
>>isn't something about that function (or calling it) that is mucking up the
>>works. what that would leave is the altering of the hook structure but (in
>>theory) have no real effect since the hook order is the same as it was going in.
>>
>
> That makes a difference: The original test suite now gets as far as the
> second test (-DReallyLast)
> There's nothing interesting in the error_log, and the test suite is
> aborted there. I assume the failure is simply because what's being
> tested for hasn't actually been done this time.
right - the test should fail because the order hasn't actually changed here.
but it ran.
so cool, we've isolated the "I can't start problem" to something in
apr_hook_sort_all().
so I guess the place to start looking is apr_hooks.c. I'll take a look at
it some more and throw in some debugging statement to see if anything jumps
out at me. one thing I've done already is to add some more details to the
core sort (attached). that gives me stuff like this:
[ from setup_prelinked_modules I think ]
Sorting translate_name: core.c (30)
[ from the main loop ]
Sorting translate_name: mod_perl.c (-10) mod_proxy.c (0) mod_rewrite.c (0)
mod_hook_order.c (0) mod_alias.c (10) mod_userdir.c (10) mod_vhost_alias.c
(10) core.c (30)
[ for mod_perl's post-config call ]
Sorting translate_name: mod_proxy.c (0) mod_rewrite.c (0) mod_hook_order.c
(0) mod_alias.c (10) mod_userdir.c (10) mod_vhost_alias.c (10) mod_perl.c
(30) core.c (30)
anyway, probably unimportant but I wanted to make sure that my new int
didn't get corrupt someplace. ymmv :)
>>anyway, thanks so much for taking the time to play with this. I hope it's
>>fun at least :)
>>
>
> For the appropriate definition of "fun", yes ;)
:)
--Geoff
Re: dynamic request hook ordering (take 2)
Posted by Steve Hay <st...@uk.radan.com>.
Geoffrey Young wrote:
>>The ReallyFirst test runs OK on its own, though.
>>
>>
>
>it seems I forgot to add a -DReallyFirst, so this is running the default as
>well.
>
Doh! Have you added it now? I've built & installed this new patch and
I still find that -DReallyFirst works fine...
>
>
>
>>
>>
>>>finally, is there something screwy with my IO in t/TEST - if you take out
>>>all the open and print foo does the problem go away? that was mostly for my
>>>debugging information anyway...
>>>
>>>
>>>
>>Removing all the open/print/close stuff makes no difference.
>>
>>
>
>ok. I don't suppose that sleeping between startups makes a difference?
>
Sleeping between what? One test /on its own/ doesn't work!
In fact, even this produces the usual error in the log and crashes the
server:
C:\Temp\hook_order_test-mp2>C:/apache2/bin/Apache.exe -d
C:/Temp/hook_order_test-mp2/t -f
C:/Temp/hook_order_test-mp2/t/conf/httpd.conf -D APACHE2 -D
PERL_USEITHREADS -D ReallyLast -X
(That's what I was running through the debugger. I meant to say.)
>[...]
>
>
>I spent the entire morning trolling through the winnt mpm and win32 API
>documentation and I'm stumped - I can't see the interaction between this
>code and what I'm doing at all. furthermore, the two events are created far
>_after_ I am finished doing stuff, since ap_run_mpm is called after
>post-config, so it's not like I am erasing a previously initialized state.
>
>anyway, attached is yet another patch. the main difference here is in the
>pools, so maybe that will have a positive effect :)
>
Sadly not. I still get the same failure as before.
>stas at one point
>suggested nulling the table when I'm done with it, which might also be an
>idea - IIRC, there is some config-parsing done on shutdown as well, so maybe
>something is getting stuck using the table created with a dead pool or
>something.
>
[I'll try your other (off-list) patch in a moment]
>
>the only thing I could suggest at this point is to comment out the
>apr_hook_sort_all() call in modperl_apache_resort_hooks() to see if there
>isn't something about that function (or calling it) that is mucking up the
>works. what that would leave is the altering of the hook structure but (in
>theory) have no real effect since the hook order is the same as it was going in.
>
That makes a difference: The original test suite now gets as far as the
second test (-DReallyLast), which does this:
C:\apache2\bin\Apache.exe -d C:/Temp/hook_order_test-mp2/t -f
C:/Temp/hook_order_test-mp2/t/conf/httpd.conf -D APACHE2 -D
PERL_USEITHREADS -D ReallyLast
using Apache/2.0.48 (winnt MPM)
waiting 60 seconds for server to start: .
waiting 60 seconds for server to start: ok (waited 0 secs)
server localhost:8529 started
t\01first....skipped
all skipped: no reason given
t\02last.....# Failed test 1 in t\02last.t at line 42
t\02last.....FAILED test 1
Failed 1/1 tests, 0.00% okay
t\03mix......skipped
all skipped: no reason given
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t\02last.t 1 1 100.00% 1
2 tests skipped.
There's nothing interesting in the error_log, and the test suite is
aborted there. I assume the failure is simply because what's being
tested for hasn't actually been done this time.
All the tests run OK (albeit with similar failures) in isolation.
>
>anyway, thanks so much for taking the time to play with this. I hope it's
>fun at least :)
>
For the appropriate definition of "fun", yes ;)
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: dynamic request hook ordering (take 2)
Posted by Steve Hay <st...@uk.radan.com>.
Geoffrey Young wrote:
>Geoffrey Young wrote:
>
>
>>stas at one point
>>suggested nulling the table when I'm done with it, which might also be an
>>idea
>>
>>
>
>to that end, here is yet another patch to try.
>
Nope :( Still the same results for me I'm afraid.
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: dynamic request hook ordering (take 2)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>>I'm still unclear as to whether this is a fault of the new hook-ordering
>>implementation, or a symptom of the way I chose to setup the tests. does it
>>behave the same way against pristine mod_perl CVS?
>>
>
> How can I try that?! If I run it against pristine mp2 CVS then it
> complains "Invalid command 'PerlHookPostReadRequestHandler'" etc ;)
ah, yes. duh :)
I guess what I was getting at, though, is the start/stop/start idea, but
your other work shows that's not an issue.
>>likewise, if you comment out everything in t/TEST save one test (any one
>>save the first, which doesn't excercise the new directives) does the
>>individual test pass?
>>
>
> The first test alone obviously runs OK, and more importantly multiple
> runs of the first test go OK:
>
> Apache::TestRunPerl->new->run(@ARGV, '-defines', '');
> Apache::TestRunPerl->new->run(@ARGV, '-defines', '');
ok.
>
> The ReallyLast, Last and Mix tests all fail when tried out
> individually.
rats. it seems that the issue is clearly related to what I'm doing then.
it's almost like I suspected, that this feature would be adding a bit of
instability for little value. but I/we are hip deep in it now, so it might
as well get fixed rather than abandoned ;)
> The ReallyFirst test runs OK on its own, though.
it seems I forgot to add a -DReallyFirst, so this is running the default as
well.
>
>
>>finally, is there something screwy with my IO in t/TEST - if you take out
>>all the open and print foo does the problem go away? that was mostly for my
>>debugging information anyway...
>>
>
> Removing all the open/print/close stuff makes no difference.
ok. I don't suppose that sleeping between startups makes a difference?
>
> (I'm testing this with "perl -Mblib t/TEST.PL" rather than "nmake test",
> btw.)
sounds fine to me.
>
> Still can't understand where that "Invalid handle" error comes from.
> Here's what's on the call stack when that error comes out:
>
> child_main(apr_pool_t * 0x6ff1d724) line 946
> ap_mpm_run(apr_pool_t * 0x0026abd8, apr_pool_t * 0x00848240, server_rec
> * 0x0026ca70) line 1629
> main(int 4201858, const char * const * 0x0000000c) line 660 + 13 bytes
> APACHE! mainCRTStartup + 227 bytes
> KERNEL32! 77e814c7()
>
> The (HANDLE *) child_events that is passed to WaitForMultipleObjects()
> on line 935 of server/mpm/winnt/child.c is a pointer to an array of
> object handles. The first argument (here, 2) specifies the number of
> object handles in that array. Here's what the MSVC debugger shows for
> child_events as it is passed to WaitForMultipleObjects:
>
> child_events 0x0006fed4
> [0] 0x00000cb0
> [1] 0x00000000
>
> The two events are exit_event and max_requests_per_child_event
> respectively. Is it significant that the latter is NULL and the former
> is not? Are they both supposed to be NULL or non-NULL? Maybe the NULL
> one is the "invalid handle", but why does it happen? There is a comment
> in the code about thread exits not being checked. I don't know if
> that's relevant or not?
>
> I tried increasing ThreadsPerChild further, and fiddled with
> MaxRequestsPerChild too, but to no avail.
I spent the entire morning trolling through the winnt mpm and win32 API
documentation and I'm stumped - I can't see the interaction between this
code and what I'm doing at all. furthermore, the two events are created far
_after_ I am finished doing stuff, since ap_run_mpm is called after
post-config, so it's not like I am erasing a previously initialized state.
anyway, attached is yet another patch. the main difference here is in the
pools, so maybe that will have a positive effect :) stas at one point
suggested nulling the table when I'm done with it, which might also be an
idea - IIRC, there is some config-parsing done on shutdown as well, so maybe
something is getting stuck using the table created with a dead pool or
something.
the only thing I could suggest at this point is to comment out the
apr_hook_sort_all() call in modperl_apache_resort_hooks() to see if there
isn't something about that function (or calling it) that is mucking up the
works. what that would leave is the altering of the hook structure but (in
theory) have no real effect since the hook order is the same as it was going in.
anyway, thanks so much for taking the time to play with this. I hope it's
fun at least :)
--Geoff
Re: dynamic request hook ordering (take 2)
Posted by Steve Hay <st...@uk.radan.com>.
Geoffrey Young wrote:
>>I've now got the same problem as you, Randy -- it runs one set of tests
>>OK (all successful), but then hangs trying to start the server the
>>second time.
>>
>>
>
>consistency is good :)
>
>I'm still unclear as to whether this is a fault of the new hook-ordering
>implementation, or a symptom of the way I chose to setup the tests. does it
>behave the same way against pristine mod_perl CVS?
>
How can I try that?! If I run it against pristine mp2 CVS then it
complains "Invalid command 'PerlHookPostReadRequestHandler'" etc ;)
>
>likewise, if you comment out everything in t/TEST save one test (any one
>save the first, which doesn't excercise the new directives) does the
>individual test pass?
>
The first test alone obviously runs OK, and more importantly multiple
runs of the first test go OK:
Apache::TestRunPerl->new->run(@ARGV, '-defines', '');
Apache::TestRunPerl->new->run(@ARGV, '-defines', '');
The ReallyLast, Last and Mix tests all fail when tried out
individually. The ReallyFirst test runs OK on its own, though.
>
>finally, is there something screwy with my IO in t/TEST - if you take out
>all the open and print foo does the problem go away? that was mostly for my
>debugging information anyway...
>
Removing all the open/print/close stuff makes no difference.
(I'm testing this with "perl -Mblib t/TEST.PL" rather than "nmake test",
btw.)
Still can't understand where that "Invalid handle" error comes from.
Here's what's on the call stack when that error comes out:
child_main(apr_pool_t * 0x6ff1d724) line 946
ap_mpm_run(apr_pool_t * 0x0026abd8, apr_pool_t * 0x00848240, server_rec
* 0x0026ca70) line 1629
main(int 4201858, const char * const * 0x0000000c) line 660 + 13 bytes
APACHE! mainCRTStartup + 227 bytes
KERNEL32! 77e814c7()
The (HANDLE *) child_events that is passed to WaitForMultipleObjects()
on line 935 of server/mpm/winnt/child.c is a pointer to an array of
object handles. The first argument (here, 2) specifies the number of
object handles in that array. Here's what the MSVC debugger shows for
child_events as it is passed to WaitForMultipleObjects:
child_events 0x0006fed4
[0] 0x00000cb0
[1] 0x00000000
The two events are exit_event and max_requests_per_child_event
respectively. Is it significant that the latter is NULL and the former
is not? Are they both supposed to be NULL or non-NULL? Maybe the NULL
one is the "invalid handle", but why does it happen? There is a comment
in the code about thread exits not being checked. I don't know if
that's relevant or not?
I tried increasing ThreadsPerChild further, and fiddled with
MaxRequestsPerChild too, but to no avail.
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: dynamic request hook ordering (take 2)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> I've now got the same problem as you, Randy -- it runs one set of tests
> OK (all successful), but then hangs trying to start the server the
> second time.
consistency is good :)
I'm still unclear as to whether this is a fault of the new hook-ordering
implementation, or a symptom of the way I chose to setup the tests. does it
behave the same way against pristine mod_perl CVS?
likewise, if you comment out everything in t/TEST save one test (any one
save the first, which doesn't excercise the new directives) does the
individual test pass?
finally, is there something screwy with my IO in t/TEST - if you take out
all the open and print foo does the problem go away? that was mostly for my
debugging information anyway...
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: dynamic request hook ordering (take 2)
Posted by Steve Hay <st...@uk.radan.com>.
Randy Kobes wrote:
>On Mon, 1 Mar 2004, Steve Hay wrote:
>
>
>>What do I do with the hook_order_test-mp2.tar.gz tests? Pardon my
>>ignorance, but I have no idea where to put these files or what to do
>>with them.
>>
>>
>
>If I recall, you have the Win32 apxs installed? If so, all
>you need to do is unpack the tarball somewhere and run
> perl Makefile.PL --apxs C:\Path\to\apxs.bat
> nmake
> nmake test
>This assumes that the patched mp2 has been installed.
>
>
Thanks. I'd left off the apxs bit. Looks much better now ;)
I've now got the same problem as you, Randy -- it runs one set of tests
OK (all successful), but then hangs trying to start the server the
second time. And like you, I have this in the error_log:
...
[Mon Mar 01 18:03:59 2004] [crit] (OS 6)The handle is invalid. : Child
3592: WAIT_FAILED -- shutting down server
...
[Mon Mar 01 18:03:59 2004] [warn] (OS 995)The I/O operation has been
aborted because of either a thread exit or an application request. :
winnt_accept: Asynchronous AcceptEx failed.
[Mon Mar 01 18:03:59 2004] [info] Child 3592: Accept thread exiting.
[Mon Mar 01 18:04:00 2004] [notice] Child 3592: Released the start mutex
[Mon Mar 01 18:04:00 2004] [info] Child 3592: 50 threads blocked on the
completion port
...
Well - at least there's two of us looking at it now...
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: dynamic request hook ordering (take 2)
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 1 Mar 2004, Steve Hay wrote:
> Geoffrey Young wrote:
[ ... ]
> >ok, I'll hold off on committing then. attached is the final patch I would
> >have put in this evening, fwiw.
> >
> >as I mentioned, I'd be interested to know if the test suite I had sent runs
> >against current pristine CVS - the individual tests would fail, obviously,
> >but if the server can't start/stop/start 5 times with the given -D switches
> >then at least I'd know it wasn't my fault (at least not currently :)
> >
> I've tried out the "final" patch with CVS mp2 (at about 15:30 01 Mar
> 2004 GMT) on WinXP / MSVC++ 6 with Apache 2.0.48 / Perl 5.8.3 and I
> found that when running "nmake test" (just the standard mp2 tests) the
> server now hangs after starting up. The error_log contained:
>
> [Mon Mar 01 16:47:36 2004] [warn] Server ran out of threads to serve
> requests. Consider raising the ThreadsPerChild setting
>
> so I changed A-T/lib/Apache/TestConfig.pm in the obvious way:
>
> <IfModule mpm_winnt.c>
> ThreadsPerChild 50
> MaxRequestsPerChild 0
> </IfModule>
>
> The standard mp2 testsuite now passes all tests successful.
I forgot to mention - I've also found lately that raising
this limit is necessary.
> What do I do with the hook_order_test-mp2.tar.gz tests? Pardon my
> ignorance, but I have no idea where to put these files or what to do
> with them.
If I recall, you have the Win32 apxs installed? If so, all
you need to do is unpack the tarball somewhere and run
perl Makefile.PL --apxs C:\Path\to\apxs.bat
nmake
nmake test
This assumes that the patched mp2 has been installed.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: dynamic request hook ordering (take 2)
Posted by Steve Hay <st...@uk.radan.com>.
Geoffrey Young wrote:
>>>or you could just comment out each
>>>different startup in TEST.PL (or just TEST if you don't feel like running
>>>Makefile.PL each time) and run each one at a time.
>>>
>>>
>>I just did that - only two of the tests sequences run
>>individually - one where -defines is '' and the other when
>>it's 'ReallyFirst'. In fact, running the two together (ie,
>>when all the others are commented out) is fine - the server
>>starts, stops, and starts again fine, so that's not the
>>problem.
>>
>>
>
>blarg.
>
>ok, I'll hold off on committing then. attached is the final patch I would
>have put in this evening, fwiw.
>
>as I mentioned, I'd be interested to know if the test suite I had sent runs
>against current pristine CVS - the individual tests would fail, obviously,
>but if the server can't start/stop/start 5 times with the given -D switches
>then at least I'd know it wasn't my fault (at least not currently :)
>
I've tried out the "final" patch with CVS mp2 (at about 15:30 01 Mar
2004 GMT) on WinXP / MSVC++ 6 with Apache 2.0.48 / Perl 5.8.3 and I
found that when running "nmake test" (just the standard mp2 tests) the
server now hangs after starting up. The error_log contained:
[Mon Mar 01 16:47:36 2004] [warn] Server ran out of threads to serve
requests. Consider raising the ThreadsPerChild setting
so I changed A-T/lib/Apache/TestConfig.pm in the obvious way:
<IfModule mpm_winnt.c>
ThreadsPerChild 50
MaxRequestsPerChild 0
</IfModule>
The standard mp2 testsuite now passes all tests successful.
What do I do with the hook_order_test-mp2.tar.gz tests? Pardon my
ignorance, but I have no idea where to put these files or what to do
with them.
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: dynamic request hook ordering (take 2)
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>but you need to pass pool... so may be not... just another idea to make
>>mod_perl.c less cluttered.
>
>
> passing the pool isn't that big a deal, or I could just use
> modperl_global_get_pconf(), in which case I'll also need to use pconf for
> the logic in modperl_cmd then (instead of parms->pool) so that the table and
> data have the same lifetime. using the global pool shouldn't be a big deal,
> since it's not a lot of data (and probably won't be any for 99% of the cases
> anyway).
Thinking forward I think you want to pass it explicitly from cmd. So if we do
that temp pool/sub-pool solution we won't need to remember to change a lot of
code and hunt for those global pool uses.
>>did you have a chance to look at the temp pool? if it does what I think
>>it does (i.e. get destroyed at the end of config) then you could use it
>>instead.
>
>
> no, I didn't trace the origins of those other two pools. but as per the
> above assertion, the pools should match, right? in which case it would be
> difficult to get into the modperl_cmd.c logic.
right, see above.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: dynamic request hook ordering (take 2)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Actually, you don't even need modperl_apache_init_hook_order(), just
> move that init code into: modperl_apache_get_hook_order();
>
> void modperl_apache_get_hook_order(apr_pool_t *p) {
> if (!hook_order) {
> hook_order = apr_table_make(p, 0);
> }
> return hook_order;
> }
I had suggested that before:
>> yeah, ok. so I can keep the init in pre-config? I guess if I use the
>> pconf
>> it doesn't really matter - I can have the accessor init using pconf if
>> the
>> table is NULL. and I was doubting the lifetime of parms->pool anyway :)
>
>
> If we implement the sub-pool for temp uses, then it'll have to be in
> pre-config, so keep it there.
>
> but you need to pass pool... so may be not... just another idea to make
> mod_perl.c less cluttered.
passing the pool isn't that big a deal, or I could just use
modperl_global_get_pconf(), in which case I'll also need to use pconf for
the logic in modperl_cmd then (instead of parms->pool) so that the table and
data have the same lifetime. using the global pool shouldn't be a big deal,
since it's not a lot of data (and probably won't be any for 99% of the cases
anyway).
>
> did you have a chance to look at the temp pool? if it does what I think
> it does (i.e. get destroyed at the end of config) then you could use it
> instead.
no, I didn't trace the origins of those other two pools. but as per the
above assertion, the pools should match, right? in which case it would be
difficult to get into the modperl_cmd.c logic.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: dynamic request hook ordering (take 2)
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>>It should be:
>>
>> modperl_apache_init_hooks(p);
>>
>
>
>>void modperl_apache_init_hook_order(apr_pool_t p) {
>> hook_order = apr_table_make(p, 0);
>>}
>
>
> ok, I'll do that. I was trying to solve a very strange problem that I
> couldn't figure out (but would probably obvious to someone else, naturally)
> - I was calling my get_hook_order() function from pre-init and initializing
> it, but for some reason the init wasn't taking.
>
> but I like your solution much, much better. thanks.
Actually, you don't even need modperl_apache_init_hook_order(), just move that
init code into: modperl_apache_get_hook_order();
void modperl_apache_get_hook_order(apr_pool_t *p) {
if (!hook_order) {
hook_order = apr_table_make(p, 0);
}
return hook_order;
}
but you need to pass pool... so may be not... just another idea to make
mod_perl.c less cluttered.
did you have a chance to look at the temp pool? if it does what I think it
does (i.e. get destroyed at the end of config) then you could use it instead.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: dynamic request hook ordering (take 2)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> It should be:
>
> modperl_apache_init_hooks(p);
>
> void modperl_apache_init_hook_order(apr_pool_t p) {
> hook_order = apr_table_make(p, 0);
> }
ok, I'll do that. I was trying to solve a very strange problem that I
couldn't figure out (but would probably obvious to someone else, naturally)
- I was calling my get_hook_order() function from pre-init and initializing
it, but for some reason the init wasn't taking.
but I like your solution much, much better. thanks.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: dynamic request hook ordering (take 2)
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
> Index: src/modules/perl/mod_perl.c
> ===================================================================
> RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v
> retrieving revision 1.210
> diff -u -r1.210 mod_perl.c
> --- src/modules/perl/mod_perl.c 1 Mar 2004 04:24:00 -0000 1.210
> +++ src/modules/perl/mod_perl.c 1 Mar 2004 04:57:56 -0000
> @@ -543,6 +543,11 @@
> {
> /* we can't have PerlPreConfigHandler without first configuring mod_perl */
>
> + /* PerlHook*Handler support */
> + apr_table_t *hook_order = apr_table_make(p, 0);
why the duplicate? You already have hook_order static var in modperl_apache.c
It should be:
modperl_apache_init_hooks(p);
with the above code moved to modperl_apache.c.
(see below).
> + modperl_apache_set_hook_order(hook_order);
no need for this function at all.
> /* perl 5.8.1+ */
> modperl_hash_seed_init(p);
>
> @@ -573,6 +578,9 @@
> modperl_trace_logfile_set(s->error_log);
> #endif
>
> + /* fixup the placement of user-defined Perl*Handlers in the hook order */
> + modperl_apache_resort_hooks();
yup, just like that one. two calls from mod_perl.c but none really gets/passes
hook_order.
> --- /dev/null 2003-01-30 05:24:37.000000000 -0500
> +++ src/modules/perl/modperl_apache.c 2004-02-29 23:42:16.000000000 -0500
> @@ -0,0 +1,115 @@
> +#include "mod_perl.h"
> +
> +/* PerlHook*Handler support */
> +static apr_table_t *hook_order;
> +
> +apr_table_t *modperl_apache_get_hook_order() {
> + return hook_order;
> +}
void modperl_apache_init_hook_order(apr_pool_t p) {
hook_order = apr_table_make(p, 0);
}
> +void modperl_apache_set_hook_order(apr_table_t *set_order) {
> + hook_order = set_order;
> +}
nuke that one.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: dynamic request hook ordering (take 2)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> or you could just comment out each
>>different startup in TEST.PL (or just TEST if you don't feel like running
>>Makefile.PL each time) and run each one at a time.
>
>
> I just did that - only two of the tests sequences run
> individually - one where -defines is '' and the other when
> it's 'ReallyFirst'. In fact, running the two together (ie,
> when all the others are commented out) is fine - the server
> starts, stops, and starts again fine, so that's not the
> problem.
blarg.
ok, I'll hold off on committing then. attached is the final patch I would
have put in this evening, fwiw.
as I mentioned, I'd be interested to know if the test suite I had sent runs
against current pristine CVS - the individual tests would fail, obviously,
but if the server can't start/stop/start 5 times with the given -D switches
then at least I'd know it wasn't my fault (at least not currently :)
anyway, thanks for tracking the issues down. talk to you soon.
--Geoff
Re: dynamic request hook ordering (take 2)
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sun, 29 Feb 2004, Geoffrey Young wrote:
>
> > Hi Geoff,
>
> hey randy. hope you had a nice vacation :)
Thanks :) Actually, it was a bunch of meetings for deciding
on some grants, which was interesting, but stressful ...
> > However, when running the tests, what happens is that the
> > tests are first run, with 01first passing and 02last and
> > 03mix being skipped. Then the server shuts down, and is
> > restarted with -DReallyLast,
>
> since these are startup-only directives, that's the only way I could think
> to do it - shutdown and restart the server a few times, each time with a
> different config.
>
> > but it times out (I raised the
> > timeout to 240 seconds, but this didn't help).
>
> argh. are you using the latest CVS, with the new "-D [space] DEFINE" stuff?
> steve mentioned a hanging apache.exe, maybe that's conflicting with the
> restart?
I don't think that's the problem - the one I'm using doesn't
have a space after the -D; from what I understand, this was
more a mp1 problem.
> > I've attached
> > the error_log - does that help in seeing what goes wrong?
>
>
> well, win32 is a mystery to me. maybe the A-T shutdown logic isn't as nice
> as we would like.
>
> I suppose you can add a few 'sleep N' calls to TEST.PL to see if giving it
> some extra time to shutdown helps. or you could just comment out each
> different startup in TEST.PL (or just TEST if you don't feel like running
> Makefile.PL each time) and run each one at a time.
I just did that - only two of the tests sequences run
individually - one where -defines is '' and the other when
it's 'ReallyFirst'. In fact, running the two together (ie,
when all the others are commented out) is fine - the server
starts, stops, and starts again fine, so that's not the
problem. The failures all lead to
[Sun Feb 29 22:11:42 2004] [crit] (OS 6)The handle is
invalid. : Child 3168: WAIT_FAILED -- shutting down server
[Sun Feb 29 22:11:42 2004] [debug] child.c(695): Child 3168:
Worker thread 19 starting.
[Sun Feb 29 22:11:42 2004] [warn] (OS 995)The I/O operation
has been aborted because of either a thread exit or an
application request. : winnt_accept: Asynchronous AcceptEx
failed.
occurring in the error log.
I'll try to track down where the invalid handle is coming
from ....
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: dynamic request hook ordering (take 2)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Hi Geoff,
hey randy. hope you had a nice vacation :)
> I've tried this out on Win32 - nice work! Just a small
> thing - in src/modules/perl/modperl_apache.c, there's a
> declaration of 'int j' in modperl_apache_resort_hooks() that
> VC++ didn't like occurring so late - moving it up near the
> beginning where 'int i' is declared fixes that.
ok, I'll fix that. I am running my final test now before committing.
> However, when running the tests, what happens is that the
> tests are first run, with 01first passing and 02last and
> 03mix being skipped. Then the server shuts down, and is
> restarted with -DReallyLast,
since these are startup-only directives, that's the only way I could think
to do it - shutdown and restart the server a few times, each time with a
different config.
> but it times out (I raised the
> timeout to 240 seconds, but this didn't help).
argh. are you using the latest CVS, with the new "-D [space] DEFINE" stuff?
steve mentioned a hanging apache.exe, maybe that's conflicting with the
restart?
> I've attached
> the error_log - does that help in seeing what goes wrong?
> [Sun Feb 29 22:11:42 2004] [crit] (OS 6)The handle is invalid. : Child 3168: WAIT_FAILED -- shutting down server
> [Sun Feb 29 22:11:42 2004] [debug] child.c(695): Child 3168: Worker thread 19 starting.
> [Sun Feb 29 22:11:42 2004] [warn] (OS 995)The I/O operation has been aborted because of either a thread exit or an application request. : winnt_accept: Asynchronous AcceptEx failed.
well, win32 is a mystery to me. maybe the A-T shutdown logic isn't as nice
as we would like.
I suppose you can add a few 'sleep N' calls to TEST.PL to see if giving it
some extra time to shutdown helps. or you could just comment out each
different startup in TEST.PL (or just TEST if you don't feel like running
Makefile.PL each time) and run each one at a time.
just to make sure it's the A-T logic and not the new patch, I'd be curious
if running the same test again from TEST.PL gives the same result without
patched sources. that is, without the test ordering foo added to the
mod_perl sources, can you
Apache::TestRunPerl->new->run(@ARGV, '-defines', '');
Apache::TestRunPerl->new->run(@ARGV, '-defines', '');
from t/TEST and have it work?
sorry to make you go through all this, though, especially when you're
testing for my benefit :) but thanks a ton for taking the time.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: dynamic request hook ordering (take 2)
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sun, 29 Feb 2004, Geoffrey Young wrote:
> here's another pass that incorporates the suggestions thus
> far. comments on the global foo appreciated. the tests I
> posted before are still valid at this point.
>
> --Geoff
Hi Geoff,
I've tried this out on Win32 - nice work! Just a small
thing - in src/modules/perl/modperl_apache.c, there's a
declaration of 'int j' in modperl_apache_resort_hooks() that
VC++ didn't like occurring so late - moving it up near the
beginning where 'int i' is declared fixes that.
However, when running the tests, what happens is that the
tests are first run, with 01first passing and 02last and
03mix being skipped. Then the server shuts down, and is
restarted with -DReallyLast, but it times out (I raised the
timeout to 240 seconds, but this didn't help). I've attached
the error_log - does that help in seeing what goes wrong?
--
best regards,
randy
Re: dynamic request hook ordering (take 2)
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
> Stas Bekman wrote:
>
>>Geoffrey Young wrote:
>>
>>
>>>>Much better, but still why having any data at all in mod_perl.c? Have
>>>>the static variable in modperl_apache.c and provide an accessor to do:
>>>>
>>>>hook_order = apr_table_make(p, 0);
>>>>
>>>>from modperl_apache.c. Now you are all set.
>>>
>>>
>>>
>>>well, I can't see where to draw the pool from or how else to inialize it.
>>>that is, unless I just make the declaration
>>>
>>>static *hook_order = apr_table_make(modperl_global_get_pconf(), 0);
>>
>>
>>You could do that. But I was merely suggesting to have a function
>>defined in modperl_apache.c that you will call from mod_perl.c, instead
>>of accessing the raw variable.
>
>
> yeah, ok. so I can keep the init in pre-config? I guess if I use the pconf
> it doesn't really matter - I can have the accessor init using pconf if the
> table is NULL. and I was doubting the lifetime of parms->pool anyway :)
If we implement the sub-pool for temp uses, then it'll have to be in
pre-config, so keep it there.
>>I'm also thinking that we have this and a few other things that are used
>>only at the server startup and are no longer needed at run time. So may
>>be we should really create a sub-pool and destroy it when we are done
>>with it? e.g. create it at the preconfig phase and destroy it at the
>>postconfig phase? So we will save a bit of a memory.
>
>
> yeah, that might be a good idea.
BTW, what the temp_pool is for? Isn't that exactly the kind of pool that we
want to use for config only things, that can be nuked when we are done? Does
it get destroyed after the startup?
>>But that of course can be done separately, after you roll this change in.
>
>
> ok, cool. I'll give the logic another once over and commit it tomorrow.
So you'd be the first one to commit in Spring ;) Unless gozer beats you with
his static modperl build ;)
> I really, really appreciate the feedback and pointers. thanks.
;)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: dynamic request hook ordering (take 2)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> Geoffrey Young wrote:
>
>>> Much better, but still why having any data at all in mod_perl.c? Have
>>> the static variable in modperl_apache.c and provide an accessor to do:
>>>
>>> hook_order = apr_table_make(p, 0);
>>>
>>> from modperl_apache.c. Now you are all set.
>>
>>
>>
>> well, I can't see where to draw the pool from or how else to inialize it.
>> that is, unless I just make the declaration
>>
>> static *hook_order = apr_table_make(modperl_global_get_pconf(), 0);
>
>
> You could do that. But I was merely suggesting to have a function
> defined in modperl_apache.c that you will call from mod_perl.c, instead
> of accessing the raw variable.
yeah, ok. so I can keep the init in pre-config? I guess if I use the pconf
it doesn't really matter - I can have the accessor init using pconf if the
table is NULL. and I was doubting the lifetime of parms->pool anyway :)
>
> I'm also thinking that we have this and a few other things that are used
> only at the server startup and are no longer needed at run time. So may
> be we should really create a sub-pool and destroy it when we are done
> with it? e.g. create it at the preconfig phase and destroy it at the
> postconfig phase? So we will save a bit of a memory.
yeah, that might be a good idea.
>
> But that of course can be done separately, after you roll this change in.
ok, cool. I'll give the logic another once over and commit it tomorrow.
I really, really appreciate the feedback and pointers. thanks.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: dynamic request hook ordering (take 2)
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>Much better, but still why having any data at all in mod_perl.c? Have
>>the static variable in modperl_apache.c and provide an accessor to do:
>>
>>hook_order = apr_table_make(p, 0);
>>
>>from modperl_apache.c. Now you are all set.
>
>
> well, I can't see where to draw the pool from or how else to inialize it.
> that is, unless I just make the declaration
>
> static *hook_order = apr_table_make(modperl_global_get_pconf(), 0);
You could do that. But I was merely suggesting to have a function defined in
modperl_apache.c that you will call from mod_perl.c, instead of accessing the
raw variable.
I'm also thinking that we have this and a few other things that are used only
at the server startup and are no longer needed at run time. So may be we
should really create a sub-pool and destroy it when we are done with it? e.g.
create it at the preconfig phase and destroy it at the postconfig phase? So we
will save a bit of a memory.
But that of course can be done separately, after you roll this change in.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: dynamic request hook ordering (take 2)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Much better, but still why having any data at all in mod_perl.c? Have
> the static variable in modperl_apache.c and provide an accessor to do:
>
> hook_order = apr_table_make(p, 0);
>
> from modperl_apache.c. Now you are all set.
well, I can't see where to draw the pool from or how else to inialize it.
that is, unless I just make the declaration
static *hook_order = apr_table_make(modperl_global_get_pconf(), 0);
>
> Also, this:
>
>> +/* PerlHook*Handler support */
>> +apr_table_t *hook_order;
>
>
> needs to be 'static'. Otherwise that symbol ends up in the final
> library. (again, please refer to Ulrich Drepper's paper: How to Write
> Shared Libraries http://people.redhat.com/drepper/ukuug2002slides.pdf)
k, thanks.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: dynamic request hook ordering (take 2)
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
> here's another pass that incorporates the suggestions thus far. comments on
> the global foo appreciated. the tests I posted before are still valid at
> this point.
Much better, but still why having any data at all in mod_perl.c? Have the
static variable in modperl_apache.c and provide an accessor to do:
hook_order = apr_table_make(p, 0);
from modperl_apache.c. Now you are all set.
Also, this:
> +/* PerlHook*Handler support */
> +apr_table_t *hook_order;
needs to be 'static'. Otherwise that symbol ends up in the final library.
(again, please refer to Ulrich Drepper's paper: How to Write Shared Libraries
http://people.redhat.com/drepper/ukuug2002slides.pdf)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org