I guess I am slowly starting to understand what's happening. I've built
modperl on other machine which has perl with ithreads, at least perl -V
produces:
[quote]
osname=aix, osvers=5.1.0.0, archname=aix-thread-multi
config_args=''
hint=previous, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
[unquote]
APR/APU config hast -lpthreads in it, and modperl Makefile has
-lpthreads and _THREAD_SAFE macro defined.
The result of t/cgi.t test is exactly the same as you described,
error_log shows:
[error] Global $r object is not available. Set:\n\tPerlOptions +GlobalRequest\nin
httpd.conf at /usr/local/li
b/perl5/5.8.5/CGI.pm line 315.\n
There must be something wrong with static variables then, threads
implementation on this platform is good enough to my belief for major
software like Oracle, Apache or perl. We seem to be fairly close to
positive result, I guess. I'll try to investigate, make
some tests and revert back to you as soon as there are any results.
Regards
Alexei
[skipped]
SB> (gdb) n
SB> 41 MpReqSET_GLOBAL_REQUEST_On(rcfg);
SB> (gdb) p *MP_tls_request_rec
SB> $29 = {flags = 0, data = 0x0, name = 0x0}
SB> As you can see it ain't working. So obviously when later on it tries to
SB> get that data out and use it, it fails and hence you get this kind of
SB> errors:
SB> Global $r object is not available. Set:\n\tPerlOptions
SB> +GlobalRequest\nin httpd.conf at ...
SB> So, are you aware with problems of using static variables on your
SB> platform? Is it compiler specific? Does it get them optimized away or
SB> something?
SB> If you rebuild your perl with ithreads and APR has ithreads too, which
SB> seems to be the case, since it links pthread
[skipped]
** Mother Nature is a bitch.
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
