Other references that use system(1,$cmd) are:
http://www.nntp.perl.org/group/perl.perl5.porters/108584
http://www.perl.com/pub/a/1999/11/p5pdigest/THISWEEK-19991107.html#system_1_foo

The limit is 64 processes at which point a error code of 'Resource temporarily unavailable' is being generated somewhere. I think you found a bug in Perl.

What appears to be happening is that even though you are requesting an asynchronous process with the system 1, ...; call, and that is being honoured, Perl is still adding the process handle to it's array of things to wait for. But as this is an asynchronous process, it never is waited for and so the process handle is never subsequently removed. Once the 64 limit is reached, it refuses to attempt to start any more, (even if the processes have been terminated!), because it has no where to left to stash the handle

It basically a good old fashioned memory leak, and you should raise a Perlbug against it. You can reduce the demonstration code to

P:\test>perl -wle"system(1,'notepad')==-1 && print qq[failed $_ proces
+s with: $!] for 1..65"
failed 65 process with: Resource temporarily unavailable
[download]

Warning: If you decide to run the above, I'd recommend enabling the "Group similar taskbar buttons" on the taskbar properties page. It'll allow you to close all 64 notepads in one click "Close group" from the context menu.

The bit I do not understand about this is that the storing of the process handles for asynchronous processes appears to be deliberate. From Win32.c:Win32_spawnvp()

    case P_NOWAIT:    /* asynch + remember result */
    if (w32_num_children >= MAXIMUM_WAIT_OBJECTS) {
        errno = EAGAIN;
        ret = -1;
        goto RETVAL;
    }
...
    if (mode == P_NOWAIT) {
        /* asynchronous spawn -- store handle, return PID */
        ret = (int)ProcessInformation.dwProcessId;
        if (IsWin95() && ret < 0)
            ret = -ret;

        w32_child_handles[w32_num_children] = ProcessInformation.hProc
+ess;
        w32_child_pids[w32_num_children] = (DWORD)ret;
        ++w32_num_children;
    }
[download]

Which suggests that the intent is that it should be possible to use wait to reap asynchronous kids and retrieve their exit codes, but nothing I've tried will allow this to work.

---

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

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

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

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

You know, I have never raised a Perl bug. How do I go about doing it?

-------------------------------
by me
http://www.basgetti.com
http://www.kidlins.com

Very interesting, thanks for explaining. Perhaps the problem is then related to having too many processes spawned?

Scott

Yep. After reading your first reply I thought I would try to rewrite the code without using the system command that way and instead calling start. It worked! Hmm, so now I wonder what the limits of calling system(1,foo) are? Is this a limitation in Perl? What is really happening here?

Fixed code below:


#!perl
use strict;
my $dir=shift || die "no image dir";
my $viewcmd=qq|rundll32.exe C:\\WINDOWS\\System32\\Shimgvw.dll,ImageVi
+ew_Fullscreen|;
opendir(DIR,$dir) || die "Error opening $dir\: $!";
my @files=grep(/\w/,readdir(DIR));
close(DIR);

foreach my $file (@files){
    my $absfile="$dir\\$file";
    next if $absfile!~/\.(jpg|gif|bmp)$/is;
    my $syscmd=qq|start $viewcmd $absfile|;
    print "$syscmd\n";
    system($syscmd);
    select(undef,undef,undef,.5);
    }
[download]

-------------------------------
by me
http://www.basgetti.com
http://www.kidlins.com

I have been coding in Perl for years but did not discover this 'undocumented' feature until recently

Its documented in perlport. (specifically here)