Re: speeding up XS_DBI_dispatch()

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?

> 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.