in reply to Re^3: DBI and fork() on Win32
in thread DBI and fork() on Win32

I'm ready to just give up... Got rid of the fork() and replaced with
system(1, "perl", "child-script", $job);
This crashes too, even when 'child-script' contains just two lines:
print "hello world\n"; exit;

Replies are listed 'Best First'.
Re^5: DBI and fork() on Win32
by Corion (Patriarch) on Feb 10, 2009 at 15:46 UTC

    You need to be a bit more precise because the following Works On My Machine:

    #!perl -w use strict; use DBI; my $dsn = 'dbi:SQLite:dbname=tmp.sqlite'; while (1) { my $dbh = DBI->connect($dsn,undef,undef,{RaiseError => 1}); # Parent + connecting # .. get a job list .. my @jobs = qw(Corion FloydATC FloydATD); $dbh->disconnect(); # <-- NB! foreach my $job (@jobs) { my @cmd = ($^X, '-le', q{"print 'Processing ', join '_', @ARGV"}, +$job); system(1, @cmd); } sleep 1; } print "Done.";

    Of course, I'm not really doing anything with the DBI handle, but maybe you can try my version and then work your way up to your version.

      This will only start up to 63 child processes before system(1, ...) will start failing.

      You could either capture the return value of the system(1, ...) call, which is a PID, or more generally just use the sample code from the waitpid() documentation before calling system(1, ...) to reap all zombie processes.

      This is necessary because Perl keeps these PIDs together with the PIDs returned by the fork() emulation in a single table that has a limit of 63 entries. This somewhat arbitrary number comes from the WaitForMultipleObjects() Windows API that is used in the implementation of wait().

        Yup after the not-so-subtle hint in the direction of perlport I read up on this ugly thing that is system(1, ...) and figured as much. Thanks :-)
      Indeed, it works now, I was tripped by a typo. Now for the next interesting challenge...
      The process cannot access the file because it is being used by another + process.
      And people actually PAY for this operating system.