Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Proc-Fork CPAN distribution.

Report information
The Basics
Id: 21768
Status: rejected
Priority: 0/
Queue: Proc-Fork

People
Owner: ARISTOTLE [...] cpan.org
Requestors: whatever [...] davidnicol.com
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)



Subject: suggestion: "reap" method
I tried to send this to Eric Roode but the e-mail bounced the docs could say something about waiting, esp. in the inet server example -- setting $SIG{CHLD}='IGNORE' with a comment would be enough; unless proc::fork does something with waiting already. Perhaps a new method, C<reap> which would happen when the child ends and work like the other three? I see that ignoring children is in the current version, along with the retry method which makes sense too; would a reap method make sense? Proc::Fork would have to own the CHLD handler, or offer a waiting hook, or both.
On Thu Sep 28 15:38:07 2006, DAVIDNICO wrote: Show quoted text
> I tried to send this to Eric Roode but the e-mail bounced
He is no longer the maintainer of the module anyway. Show quoted text
> the docs could say something about waiting, esp. in the inet server > example -- setting $SIG{CHLD}='IGNORE' with a comment would be enough;
Several of the examples do that already; should others as well? I'm not actually particularly versed in the subject, so if you want to provide a doc patch, I'd be most grateful. Show quoted text
> unless proc::fork does something with waiting already.
Not at all, it’s really just syntactic sugar for Perl's C<fork> function, nothing more. Show quoted text
> I see that ignoring children is in the current version,
Where? I don't remember seeing that in the code and I can't find it now either. Show quoted text
> along with the retry method which makes sense too; would a reap method > make sense? Proc::Fork would have to own the CHLD handler, or offer > a waiting hook, or both.
How would I implement both a C<reap> and C<parent> block though? Do you have any suggestions? If you want, just take a look at the source. It is very short, as you'd expect of such a single-tiny-purpose module.
Subject: Re: [rt.cpan.org #21768] suggestion: "reap" method
Date: Tue, 3 Oct 2006 16:56:51 -0500
To: bug-Proc-Fork [...] rt.cpan.org
From: "David Nicol" <davidnico [...] cpan.org>
On 10/2/06, Aristotle Pagaltzis via RT <bug-Proc-Fork@rt.cpan.org> wrote: Show quoted text
> How would I implement both a C<reap> and C<parent> block though? Do you > have any suggestions? If you want, just take a look at the source. It is > very short, as you'd expect of such a single-tiny-purpose module.
the parent block happens immediately, the reap block happens in the parent, should it live so long, when the child exits. Here are a patch implementing a reap clause and a revised test program. (I haven't actually run the test at this time but I think it should work ... <g/> ) -- The Country Of The Blind, by H.G. Wells http://cronos.advenge.com/pc/Wells/p528.html

Message body is not shown because sender requested not to inline it.

Message body is not shown because sender requested not to inline it.

I remember being confused by this request at the time. Far in retrospect, I can no longer recollect why. All I can say now is, this does not fit into the API as I think of it. Each of the blocks currently implemented relates directly to the one particular fork() call that the run_fork{} block executes. This reap{} block would have completely different scoping and timing, to which setting $SIG{CHLD} corresponds much more obviously. The mere fact that $SIG{CHLD} has something to do with fork() does not by itself justify having a knob for it in the API, IMO. $SIG{CHLD} is the right knob for $SIG{CHLD}. So, at long last, I am closing this ticket. Sorry to disappoint, but especially sorry that it took me this long.