slloyd has asked for the wisdom of the Perl Monks concerning the following question:

I am using the Windows Picture and Fax Viewer built into Windows XP as a slideshow. However, I have one slight problem that I cannot seem to figure out. After a while the Windows Picture and Fax Viewer no longer responds to the commands. Try the code below and pass in a directory that has a lot of images. It will work for the first 50 images or so and then it simply does not respond to the view requests. Does anyone have any idea why? or how to fix the problem?
#!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|$viewcmd $absfile|; print "$syscmd\n"; system(1,$syscmd); select(undef,undef,undef,3); }

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

Replies are listed 'Best First'.
Re: Slideshow using the Windows Picture and Fax Viewer
by helphand (Pilgrim) on Jan 29, 2006 at 18:02 UTC

    I don't see how your program even works one time unless you have a program named '1' or I just don't understand the system function. Someone please correct me if I'm clueless...

    system(1,$syscmd); #<-- 1 is the command executed

    You might want to check for errors there.

    system (1,$syscmd) == 0 or die "$syscmd failed: $?";

    Scott

        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

        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; }

        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.

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

        Scott

        I have been coding in Perl for years but did not discover this 'undocumented' feature until recently
        Its documented in perlport. (specifically here)