Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Parallel-ForkManager CPAN distribution.

Report information
The Basics
Id:
54566
Status:
rejected
Priority:
Low/Low

People
Owner:
Nobody in particular
Requestors:
fbicknel [...] nc.rr.com
Cc:
AdminCc:

BugTracker
Severity:
Wishlist
Broken in:
0.7.5
Fixed in:
(no value)



Subject: nowait parameter for start method
I found that sometimes I don't want ForkManager to sit around waiting for child processes to finish so that it might start another. In these cases, I may wish to return and deal with another queue for example, which I might submit using a different instance of PM. It would be nice if there were a mechanism to make ->start return if there are too many child processes to start a new one. One method might be to include a new method, ->start_no_wait for example. But I found that if you add a second parameter to ->start ($ident, $nowait), which if true would return immediately with a PID, or zero or undef. The undef would indicate that there are too many processes running; the caller should come back later. I found that a simple mod to ->start would do the trick. I include the mod below: 280 sub start { 281 my ($s,$identification, $noWait)=@_; 282 die "Cannot start another process while you are in the child process" if $s->{in_child}; 283 if ($noWait) { 284 my $kid; 285 # reap as many kids as possible (otherwise they just hang around and gum up the works) 286 do { 287 $kid = $s->wait_one_child (&WNOHANG); 288 } while $kid > 0; 289 return undef if $s->{max_proc} && ( keys %{ $s->{processes} } ) >= $s->{max_proc}; 290 } else { 291 while ($s->{max_proc} && ( keys %{ $s->{processes} } )
Show quoted text
>= $s->{max_proc}) {
292 $s->on_wait; 293 $s->wait_one_child(defined $s->{on_wait_period} ? &WNOHANG : undef); 294 }; 295 $s->wait_children; 296 } My only reservation at this point is that ->on_wait is not called as it is in the original while loop (which remains intact near line 292 above). However, I think that it's ok in this case, as we're NOT waiting, but rather just checking whether any children are finished and checking to see how many processes are running. If we fall through this last return (on line 296 above), then the next thing to do is the usual fork. The calling code would then need to check for undef returned, and if found can go on about other business. If something >= 0 is returned, then we implement the usual behavior.
From: fbicknel@nc.rr.com
It's sad that RT does not display the structure of the code. It's in there, but you can't see it. If you 'reply', then the indentation is there.
From: fbicknel@nc.rr.com
Apparently you already have a method that incorporates waiting on all the kids: ->wait_children waits on all of 'em. This reduced my proposed start method code to: 280 sub start { 281 my ($s,$identification, $noWait)=@_; 282 die "Cannot start another process while you are in the child process" if $s->{in_child}; 283 if ($noWait) { 284 # reap as many kids as possible (otherwise they just hang around and gum up the works) 285 $s->wait_children; 286 return undef if $s->{max_proc} && ( keys %{ $s->{processes} } ) >= $s->{max_proc}; 287 } else { 288 while ($s->{max_proc} && ( keys %{ $s->{processes} } )
Show quoted text
>= $s->{max_proc}) {
289 $s->on_wait; 290 $s->wait_one_child(defined $s->{on_wait_period} ? &WNOHANG : undef); 291 }; 292 $s->wait_children; 293 }
Subject: Re: [rt.cpan.org #54566] nowait parameter for start method
Date: Tue, 16 Feb 2010 02:16:26 +0000
To: bug-Parallel-ForkManager@rt.cpan.org
From: Balázs Szabó <dlux@dlux.hu>
Hi,

There are some problems with your idea:

- You cannot really use multiple Parallel::ForkManager instances in the current code.
- wait_children blocks, so it is not really suitable for inclusion in the start method.

Cheers,

Balázs

wait_childer blocks

On Mon, Feb 15, 2010 at 20:12, Frank Bicknell via RT <bug-Parallel-ForkManager@rt.cpan.org> wrote:
Show quoted text
      Queue: Parallel-ForkManager
 Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=54566 >

Apparently you already have a method that incorporates waiting on all
the kids:

->wait_children

waits on all of 'em.
 This reduced my proposed start method code to:

   280 sub start {
   281     my ($s,$identification, $noWait)=@_;
   282     die "Cannot start another process while you are in the child
process" if $s->{in_child};
   283     if ($noWait) {
   284         # reap as many kids as possible (otherwise they just
hang around and gum up the works)
   285         $s->wait_children;
   286         return undef if $s->{max_proc} && ( keys %{
$s->{processes} } ) >= $s->{max_proc};
   287     } else {
   288         while ($s->{max_proc} && ( keys %{ $s->{processes} } )
>= $s->{max_proc}) {
   289             $s->on_wait;
   290             $s->wait_one_child(defined $s->{on_wait_period} ?
&WNOHANG : undef);
   291         };
   292         $s->wait_children;
   293     }




--
Balázs Szabó (dLux)
www.dlux.hu

你很好奇
Hi, Actually what you've described is the way PFM SHOULD work. If it works otherwise, then let me know!


This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.