Re: speeding up XS_DBI_dispatch()

On 11/02/2012 13:55, Tim Bunce wrote:
> On Fri, Feb 10, 2012 at 04:48:38PM -0800, 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?
> When called from BOOT dbi_bootinit() gets passed a NULL parent_dbis
> parameter, but when called from CLONE it's not null, so this might be a
> good fix:
>
> @@ -579,7 +579,10 @@
>       gv_fetchpv("DBI::lasth",  GV_ADDMULTI, SVt_PV);
>       gv_fetchpv("DBI::rows",   GV_ADDMULTI, SVt_PV);
>
> -    if (getenv("PERL_DBI_XSBYPASS"))
> +    /* we only need to check the env var on the initial boot
> +     * which is handy because it can core dump during CLONE on windows
> +     */
> +    if (!parent_dbis&&  getenv("PERL_DBI_XSBYPASS"))
>           use_xsbypass = atoi(getenv("PERL_DBI_XSBYPASS"));
>   }
>
> Martin, could you try that?
Seems to work fine.

I have other tests failing (85gofer.t) but it is nothing to do with this 
issue and I'm looking into them.

>> 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]
>>
>> Anyways, I would suggest trying a workaround by moving the getenv()
>> call outside the cloning operation.
> Hopefully the above will do the trick. Meanwhile, aborting if getenv is
> called during a CLONE sure seems like a bug worthy of a ticket for p5p.
>
> Thanks Jan!
>
> Tim.

Martin

-- 
Martin J. Evans
Easysoft Limited
http://www.easysoft.com