Re: apr_psprintf thread safe?
Where does it say that? httpd uses it extensively, so if it's not, I'd tend to think we'd have noticed by now... --Cliff On Thu, 8 Jan 2004, Donald Doane wrote: Okay, will do that, but it's called in flood_easy_reports::easy_process_stats() and it seems APR documentation implies it is not thread safe. We use a modified version of flood_easy_reports and I'd like to confirm whether or not its use is truly thread safe. Geoffrey Young wrote: Donald Doane wrote: Can someone please confirm whether or not apr_psprintf is thread safe. Thank you. sorry, wrong list. try [EMAIL PROTECTED] --Geoff
Re: apr_psprintf thread safe?
The following comment is from apr_lib.h: * apr_vformatter does not call out to any other code, it is entirely * self-contained. This allows the callers to do things which are * otherwise unsafe. For example, apr_psprintf uses the scratch * space at the unallocated end of a block, and doesn't actually * complete the allocation until apr_vformatter returns. apr_psprintf * would be completely broken if apr_vformatter were to call anything * that used a apr_pool_t. Similarly http_bprintf() uses the scratch * space at the end of its output buffer, and doesn't actually note * that the space is in use until it either has to flush the buffer * or until apr_vformatter returns. Cliff Woolley wrote: Where does it say that? httpd uses it extensively, so if it's not, I'd tend to think we'd have noticed by now... --Cliff On Thu, 8 Jan 2004, Donald Doane wrote: Okay, will do that, but it's called in flood_easy_reports::easy_process_stats() and it seems APR documentation implies it is not thread safe. We use a modified version of flood_easy_reports and I'd like to confirm whether or not its use is truly thread safe. Geoffrey Young wrote: Donald Doane wrote: Can someone please confirm whether or not apr_psprintf is thread safe. Thank you. sorry, wrong list. try [EMAIL PROTECTED] --Geoff
Re: apr_psprintf thread safe?
On Thu, 8 Jan 2004, Donald Doane wrote: The following comment is from apr_lib.h: * apr_vformatter does not call out to any other code, it is entirely * self-contained. This allows the callers to do things which are * otherwise unsafe. For example, apr_psprintf uses the scratch * space at the unallocated end of a block, and doesn't actually * complete the allocation until apr_vformatter returns. apr_psprintf * would be completely broken if apr_vformatter were to call anything * that used a apr_pool_t. Similarly http_bprintf() uses the scratch * space at the end of its output buffer, and doesn't actually note * that the space is in use until it either has to flush the buffer * or until apr_vformatter returns. That seems to say to me that apr_psprintf is in fact threadsafe after all. :-) --Cliff
Re: apr_psprintf thread safe?
On Fri, 2004-01-09 at 04:50, Cliff Woolley wrote: [...] That seems to say to me that apr_psprintf is in fact threadsafe after all. :-) It actually depends on how apr_psprintf is called, pass it the same pool in two concurrent threads and it might blow up. Is the apr_psprintf function otherwise threadsafe? Yes. Sander
Re: apr_psprintf thread safe?
Thank you for the claification. Sander Striker wrote: On Fri, 2004-01-09 at 04:50, Cliff Woolley wrote: [...] That seems to say to me that apr_psprintf is in fact threadsafe after all. :-) It actually depends on how apr_psprintf is called, pass it the same pool in two concurrent threads and it might blow up. Is the apr_psprintf function otherwise threadsafe? Yes. Sander
Re: Regarding Apache 2.0.48 and specweb99
Joshua Schnee wrote: I am attempting to set up the latest Apache server and RHEL 64bit to use in a Specweb99 run and am running into cgi issues. I am very new to Apache, and am having difficulty getting apache to run/use/find my cgi-script. Static content works fine, but I am getting improper file returned errors on all but the command/reset. Would either of you will willing to help? I am copying the [EMAIL PROTECTED] mailing list where all the Apache specweb99 people hang out. You might want to subscribe if you are going to be working with specweb99 for a while. See http://httpd.apache.org/test/ for info on the mailing list and the project in general. There are two other sub-projects discussed on this list but the total traffic is low. OK, some questions. Are you trying to use mod_specweb99 for dynamic content, or are you trying to use just a CGI? If it's the latter, do any CGIs work for you? Apache ships two sample CGIs in the cgi-bin install directory, printenv and test-cgi. Make sure you chmod +x them or they won't work; it's a mystery to me why we install them without execute permissions. If you see the CGI code returned to the client rather than the result of executing the script, you probably need to tweak your httpd.conf to tell Apache that this is a CGI and not just a static file. Here's what I have: Directory /spec_docroot/cgi-bin Options ExecCGI SetHandler cgi-script /Directory If you can get the Apache sample CGIs to work but still have problems, you are probably seeing failures at the beginning of the run where the SPEC client tests the various types of URLs. Fortunately, the client prints the URLs before it tests them. Cut-n-paste the failing URLs into a browser navigation bar and hit enter. What does the browser display? Hope this helps. Greg
Re: Perl test framework, TestConfig, and debugging A::T
On Thu, Jan 08, 2004 at 12:57:43PM -0800, Stas Bekman wrote: It's really hard to guess what did you do. As suggested below if you could create a sample package which reproduces the problem, upload it somewhere and post the URL here, we could be much more helpful. You should be able to create this sample package without having any perl modules, only the test modules. Understood. I'll work on building a test module so that I can be more helpful in providing tests for the anomalies I keep creating g. Take a look at the modperl-2.0 suite for examples. Also see Apache-VMonitor-2.0 on CPAN which has 3 vhosts and it works just fine. OK. I use the good old print() and Data::Dumper to debug. Actually I use error() which is imported by Apache::TestTrace, and if you have env var APACHE_TEST_COLOR=1 it'll get out in red colour and it knows to handle variable references via Data::Dumper. Thanks for the info. I'll check out the error() command. I have been using APACHE_TEST_COLOR which is a very nice feature. I don't think you can use perl debugger with fork/exec, though I could be wrong. How do you invoke the debugger? exec runs exactly the same command, so it should invoke the debugger again. I've been calling it as `perl -d t/TEST`. I have tried calling it using `t/TEST -debug perl` but the debugger hangs or, more recently, I get the message '!!! server is not ready yet, try again.' Running the tests without debugging or with the gdb debugger works fine. I need to build that test module to see if I can repeat this behavior As always, thanks for your assistance, William -- Knowmad Services Inc. http://www.knowmad.com
Re: sticky preferences in Apache-Test
$ perl Makefile.PL MP_APXS=/apache/2.1/prefork/perl-5.8.2/bin/apxs ... Configuring Apache/2.1.0-dev mod_perl/1.99_13-dev Perl/v5.8.2 $ make make test ... using Apache/2.0.49-dev (prefork MPM) waiting 120 seconds for server to start: .httpd: module mod_perl.c is not compatible with this version of Apache (found 20030821, need 20020903). this seems to have gone away - it must have been a result of some stuff left over from a previous implementation. --Geoff
Re: sticky preferences in Apache-Test
Geoffrey Young wrote: $ perl Makefile.PL MP_APXS=/apache/2.1/prefork/perl-5.8.2/bin/apxs ... Configuring Apache/2.1.0-dev mod_perl/1.99_13-dev Perl/v5.8.2 $ make make test ... using Apache/2.0.49-dev (prefork MPM) waiting 120 seconds for server to start: .httpd: module mod_perl.c is not compatible with this version of Apache (found 20030821, need 20020903). this seems to have gone away - it must have been a result of some stuff left over from a previous implementation. You mean it wasn't 'cvs up'ed? Let's see if we can stay without making a modperl-2.0 build special. Why? Because it should use the modperl-2.0 build args for any 3rd party modules A-T runs, if it's installed and used. So it's really the same as modperl-2.0's make test. __ Stas BekmanJAm_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
Re: Perl test framework, TestConfig, and debugging A::T
William McKee wrote: [...] I've been calling it as `perl -d t/TEST`. I have tried calling it using `t/TEST -debug perl` but the debugger hangs or, more recently, I get the message '!!! server is not ready yet, try again.' Running the tests without debugging or with the gdb debugger works fine. I need to build that test module to see if I can repeat this behavior Yes, -debug is for debugging the server, not the test suite, so 'perl -d t/TEST' is correct. Though it seems that we don't reproduce the perl flags when doing exec. So try to change t/TEST to add -d at the end of the first line. As always, thanks for your assistance, You are very welcome ;) __ Stas BekmanJAm_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
