Re: speeding up XS_DBI_dispatch()

"Martin J. Evans" <[email protected]>
Newsgroups gmane.comp.lang.perl.modules.dbi.sybase.devel
Message-ID <[email protected]>
On 11/02/2012 00:48, Jan Dubois wrote:
> On Fri, 10 Feb 2012, Dave Mitchell wrote:
>> On Thu, Feb 09, 2012 at 11:10:17PM +0100, demerphq wrote:
>>> Well perls fork() relies on threaded  perl so it could very easily be
>>> Dave's patch. Dave do you have access to a win32 build environment?
>> I'm afraid not.
> The problem is due to the getenv() call during interpreter cloning.
> On Windows Perl keeps a virtual host environment for each interpreter,
> with its own cwd, and its own set of environment variables.  I don't
> have time to figure out _why_ this is an issue, but maybe you can check
> the environment variable during the BOOT section and just set a global
> variable instead, to work around this issue?
>
>      if (getenv("PERL_DBI_XSBYPASS"))
>          use_xsbypass = atoi(getenv("PERL_DBI_XSBYPASS"));
>
> On my old Windows 2000 system the test would simply abort with the
> message "abnormal program termination".  I was just guessing that
> this is somehow triggered by the abort() function in the C runtime.
> Setting a breakpoint on it confirms it, even though the stack trace
> looks incomplete (I don't see PerlEnvGetenv() calling abort() directly):
>
> MSVCRT!abort
> perl514!PerlEnvGetenv+0x13 [perlhost.h @ 462]
> DBI!dbi_bootinit+0x276 [DBI.xs @ 468]
> DBI!XS_DBI__clone_dbis+0x71 [DBI.c @ 4280]
> perl514!Perl_pp_entersub+0x701 [..\pp_hot.c @ 3049]
> perl514!Perl_runops_standard+0xc [..\run.c @ 41]
> perl514!Perl_call_sv+0x195 [perl.c @ 2633]
> perl514!perl_clone_using+0x18ad [..\sv.c @ 13422]
> perl514!PerlProcFork+0x89 [perlhost.h @ 1854]
> perl514!Perl_pp_fork+0x42 [..\pp_sys.c @ 4044]
> perl514!Perl_runops_standard+0xc [..\run.c @ 41]
> perl514!S_run_body+0xf5 [perl.c @ 2351]
> perl514!perl_run+0x179 [perl.c @ 2269]
> perl514!RunPerl+0xed [perllib.c @ 270]
> perl!main+0x12 [perlmain.c @ 22]
> perl!mainCRTStartup+0xe3
> KERNEL32!BaseProcessStart+0x3d
>
> Anyways, I would suggest trying a workaround by moving the getenv()
> call outside the cloning operation.
>
> Cheers,
> -Jan
>
>
Nice find Jan. Commenting out the getenv works for me.

Martin
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.