perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Hay <steve....@uk.radan.com>
Subject What Perl configuration is required for mp2 on Win32?
Date Fri, 28 Jan 2005 12:59:10 GMT
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: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message