The underlying cause is a Perl internal use of a system call WaitForMultipleObjects() which is limited to waiting on 64 objects at any given time.

From what I remember, the limitation is 64 concurrent forks. Once one completes, you can initiate another.

I forget all details, but if you'd show the basic layout of your code, I'd probably remember what you need to do to alleviate the limit.

BrowserUk,
The code looks something like this:

for my $pdf (glob('*.pdf')) {
    my $txt = convert_pdf_to_text($pdf);
    next if ! interesting($txt);
    # ...
}

sub convert_pdf_to_text {
    my ($file) = @_;
    my $abs_file = rel2abs(catfile(curdir(), $file));

    ## Start Simpo PDF To Text 
    system(1, 'C:\Program Files\Simpo PDF to Text\PDF2Text.exe');

    # Locate the window
    my $wid = WaitWindow('Simpo PDF to Text', 5);
    die "Couldn't find 'Simpo PDF to Text' window" if ! defined $wid;

    ## Make sure it is on top
    SetForegroundWindow($wid);

    # Convert PDFs
    add_pdf($abs_file);
    convert();

    # Close the application
    SendKeys('%{F4}');

    my $txt_file = construct_txt_file($file);
    return '' if ! -r $txt_file;
    my $data = read_file($txt_file);
    unlink $txt_file or die $!;
    return $data;
}
[download]

As you can see, I use system(1, $app) to start the application and alt+f4 to close the application (before starting the new one). I have already worked around the problem by leaving the app open. Just not sure why this doesn't work as I would expect.

Cheers - L~R

You don't reap. Use waitpid($pid), the pid being returned by system 1.

Either of these will work:

1. Use a synchronous system and the start command. This will synchronously run a copy of cmd.exe to run the start command, and it starts the program asynchronously.

   As cmd.exe returns immediately and the synchronous system gathers its exit code, it avoids the accumulation of zombies and the WaitForMultipleObjects() problem:

   for ( 1 .. 100 ) {
       print "spawning job $_";
       system 'start \\Windows\\system32\\notepad.exe';
       my $wid = WaitWindow( 'Notepad', 1 );
       SetForegroundWindow( $wid );
       SendKeys( '%{F4}' );
   }
   [download]

2. Use the asynchronous system and obtain the pid of the started instance from the returned value.

   Use waitpid to gather the exit code thus avoiding the accumulation of the zombies:

   for ( 1 .. 100 ) {
       print "spawning job $_";
       my $pid = system 1, '/Windows/system32/notepad.exe';
       my $wid = WaitWindow( 'Notepad', 1 );
       SetForegroundWindow( $wid );
       SendKeys( '%{F4}' );
       waitpid $pid, 1;
   }
   [download]

Finally, 'Simpo PDF to Text' has a 'batch mode' which would be possible -- if awkward -- to drive programmically, but it might be substantially more efficient.

I guess you've already looked at command line driven alternatives?

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

It appears there is a limit on the number of children perl can have under windows:

http://code.activestate.com/lists/perl-win32-users/12064

However that thread says the limit only applies to concurrent threads that perl can wait on. Perhaps your code is creating child processes to convert each PDF, and then not waiting on each process, but is leaving zombies.

There is a per process OS limit on the number of filehandles ... see FileCache/_setmaxstdio

It might also be a per-process-group limit

Use http://live.sysinternals.com/handle.exe or http://live.sysinternals.com/procexp.exe to examine the process details and open handles before hitting 64 and after

Maybe the program doesn't die, and keeps a lock open to some config file or something, thus blocking subsequent ones ...

Anonymous Monk,
That certainly seems plausible but it would mean shame on Windows for not actually releasing resources when the program is shut down (unless using alt-f4 is a bad way to close the program). Perhaps before I write all the code to keep the app open, I will try closing it through the X button.

Cheers - L~R