The mp2 docs detail what Perl configuration is required for various mp2 setups in Unixland (http://perl.apache.org/docs/2.0/user/install/install.html#Prerequisites), but there is no mention of what is required on Win32.
The Win32-specific notes (http://perl.apache.org/docs/2.0/os/win32/install.html) mention that if you are using ActivePerl then builds 8xx rather than 6xx are required, but there is no mention of what elements of the ActivePerl configuration are actually *required*. The reason that I'm asking is that I'd like to use a Perl that I've built myself with slightly different options than ActivePerl. ActivePerl is built with MULTIPLICITY, USE_ITHREADS and PERL_IMPLICIT_SYS. The first two are required to enable ithreads (which I believe is required for Win32/mp2 (correct?)); the third one is required to enable the fork() emulation (which I'm not sure if Win32/mp2 requires or not). Unfortunately, enabling PERL_IMPLICIT_SYS requires that you disable PERL_MALLOC because Perl's malloc() does not work with the implicit "host" layer. This has a serious performance hit on Win32 because MS's CRT malloc()/realloc() is desperately slow in some situations, e.g. see http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2004-12/msg00437.html. Therefore, I want to configure my Perl with MULTIPLICITY and USE_ITHREADS, but not PERL_IMPLICIT_SYS. That way, I can enable PERL_MALLOC. I've tried doing exactly this, but it doesn't seem to work. Perl (5.8.6) itself built and tested without error, and mp2 (RC4) also built without error. However, the mp2 test suite won't even get off the ground. In fact, I can't even start the mp2-enabled Apache (2.0.52) server. It crashes during startup like this: Perl_malloc(unsigned int 1020) line 1458 S_more_sv(interpreter * 0x00273f88) line 315 + 10 bytes Perl_newSV(interpreter * 0x00273f88, unsigned int 79) line 4561 + 76 bytes perl_construct(interpreter * 0x00273f88) line 267 + 11 bytes modperl_startup(server_rec * 0x0082e590, apr_pool_t * 0x0029b398) line 246 + 9 bytes modperl_startup(server_rec * 0x0082e590, apr_pool_t * 0x0029b398) line 207 + 13 bytes modperl_init(server_rec * 0x0082e590, apr_pool_t * 0x0029b398) line 453 + 13 bytes modperl_hook_init(apr_pool_t * 0x0029b398, apr_pool_t * 0x00000000, apr_pool_t * 0x00000000, server_rec * 0x0082e590) line 613 + 13 bytes modperl_run() line 627 + 21 bytes modperl_cmd_load_module(cmd_parms_struct * 0x0006fec8, void * 0x00859458, const char * 0x008e1a40) line 652 invoke_cmd(const command_struct * 0x100281e8, cmd_parms_struct * 0x0006fec8, void * 0x00859458, const char * 0x008e1a40) line 675 + 18 bytes ap_walk_config_sub(const ap_directive_t * 0x008e1a20, cmd_parms_struct * 0x0006fec8, ap_conf_vector_t * 0x0082eb60) line 1059 + 24 bytes ap_walk_config(ap_directive_t * 0x008e1a20, cmd_parms_struct * 0x0006fec8, ap_conf_vector_t * 0x0082eb60) line 1098 + 17 bytes ap_process_config_tree(server_rec * 0x0082e590, ap_directive_t * 0x00891430, apr_pool_t * 0x0029b398, apr_pool_t * 0x0084c6b0) line 1641 + 20 bytes main(int 9, const char * const * 0x00298758) line 539 mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e8141a() Line 1458 of malloc. is "MALLOC_LOCK;", which was earlier #defined as "MUTEX_LOCK(&PL_malloc_mutex)". I think (I'm not sure) that MUTEX_LOCK is defined by win32/win32thread.h on Win32. By default it seems to be: #define MUTEX_LOCK(m) EnterCriticalSection(m) and has this comment above it: /* Critical Sections used instead of mutexes: lightweight, * but can't be communicated to child processes, and can't get * HANDLE to it for use elsewhere. */ I tried rebuilding everything with /DDONT_USE_CRITICAL_SECTION which causes an alternative definition of MUTEX_LOCK to be used instead: # define MUTEX_LOCK(m) \ STMT_START { \ if (WaitForSingleObject(*(m),INFINITE) == WAIT_FAILED) \ Perl_croak_nocontext("panic: MUTEX_LOCK"); \ } STMT_END This time we start off like this: S_mess_alloc(interpreter * 0x00273f88) line 833 + 16 bytes Perl_vmess(interpreter * 0x00273f88, const char * 0x2818884c `string', char * * 0x0006fa38) line 960 + 9 bytes S_vdie_croak_common(interpreter * 0x00273f88, const char * 0x2818884c `string', char * * 0x0006fa38, unsigned int * 0x0006fa1c, long * 0x0006fa14) line 1055 + 17 bytes Perl_vcroak(interpreter * 0x00273f88, const char * 0x2818884c `string', char * * 0x0006fa38) line 1175 + 25 bytes Perl_croak_nocontext(const char * 0x2818884c `string') line 1196 + 17 bytes Perl_malloc(unsigned int 1020) line 1458 + 30 bytes S_more_sv(interpreter * 0x00273f88) line 315 + 10 bytes Perl_newSVpvn(interpreter * 0x00273f88, const char * 0x281a2830 `string', unsigned int 0) line 6861 + 76 bytes S_mess_alloc(interpreter * 0x00273f88) line 833 + 16 bytes Perl_vmess(interpreter * 0x00273f88, const char * 0x2818884c `string', char * * 0x0006fba8) line 960 + 9 bytes S_vdie_croak_common(interpreter * 0x00273f88, const char * 0x2818884c `string', char * * 0x0006fba8, unsigned int * 0x0006fb8c, long * 0x0006fb84) line 1055 + 17 bytes Perl_vcroak(interpreter * 0x00273f88, const char * 0x2818884c `string', char * * 0x0006fba8) line 1175 + 25 bytes Perl_croak_nocontext(const char * 0x2818884c `string') line 1196 + 17 bytes Perl_malloc(unsigned int 1020) line 1458 + 30 bytes S_more_sv(interpreter * 0x00273f88) line 315 + 10 bytes Perl_newSV(interpreter * 0x00273f88, unsigned int 79) line 4561 + 76 bytes perl_construct(interpreter * 0x00273f88) line 267 + 11 bytes modperl_startup(server_rec * 0x0082e590, apr_pool_t * 0x0029b398) line 246 + 9 bytes modperl_startup(server_rec * 0x0082e590, apr_pool_t * 0x0029b398) line 207 + 13 bytes modperl_init(server_rec * 0x0082e590, apr_pool_t * 0x0029b398) line 453 + 13 bytes modperl_hook_init(apr_pool_t * 0x0029b398, apr_pool_t * 0x00000000, apr_pool_t * 0x00000000, server_rec * 0x0082e590) line 613 + 13 bytes modperl_run() line 627 + 21 bytes modperl_cmd_load_module(cmd_parms_struct * 0x0006fec8, void * 0x00859458, const char * 0x008e1a40) line 652 invoke_cmd(const command_struct * 0x100281e8, cmd_parms_struct * 0x0006fec8, void * 0x00859458, const char * 0x008e1a40) line 675 + 18 bytes ap_walk_config_sub(const ap_directive_t * 0x008e1a20, cmd_parms_struct * 0x0006fec8, ap_conf_vector_t * 0x0082eb60) line 1059 + 24 bytes ap_walk_config(ap_directive_t * 0x008e1a20, cmd_parms_struct * 0x0006fec8, ap_conf_vector_t * 0x0082eb60) line 1098 + 17 bytes ap_process_config_tree(server_rec * 0x0082e590, ap_directive_t * 0x00891430, apr_pool_t * 0x0029b398, apr_pool_t * 0x0084c6b0) line 1641 + 20 bytes main(int 9, const char * const * 0x00298758) line 539 mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e8141a() and then get stuck doing this: S_mess_alloc(interpreter * 0x00273f88) line 833 + 16 bytes Perl_vmess(interpreter * 0x00273f88, const char * 0x2818884c `string', char * * 0x0006fa38) line 960 + 9 bytes S_vdie_croak_common(interpreter * 0x00273f88, const char * 0x2818884c `string', char * * 0x0006fa38, unsigned int * 0x0006fa1c, long * 0x0006fa14) line 1055 + 17 bytes Perl_vcroak(interpreter * 0x00273f88, const char * 0x2818884c `string', char * * 0x0006fa38) line 1175 + 25 bytes Perl_croak_nocontext(const char * 0x2818884c `string') line 1196 + 17 bytes Perl_malloc(unsigned int 1020) line 1458 + 30 bytes S_more_sv(interpreter * 0x00273f88) line 315 + 10 bytes Perl_newSVpvn(interpreter * 0x00273f88, const char * 0x281a2830 `string', unsigned int 0) line 6861 + 76 bytes over and over again, and eventually crash with a "Stack overflow" error. Is there any hope of solving this, or am I pissing in the wind? (i.e. is PERL_IMPLICIT_SYS / fork() emulation actually required?) - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
