From: nvp <ruby-lists@...>
Date: 2010-01-08T12:15:56+09:00
Subject: Re: RCR: fork(n) {|n| }

On Thu, Jan 7, 2010 at 4:58 PM, Daniel Berger <djberg96@gmail.com> wrote:
>
>
> On Jan 7, 10:34 am, nvp <ruby-li...@noopy.org> wrote:
>> On Thu, Jan 7, 2010 at 12:13 PM, Daniel Berger <djber...@gmail.com> wrote:
>>
>> > Not a direct answer, but this project may be of interest:
>>
>> >http://rubyforge.org/projects/parallelforkmgr/
>>
>> This is my project and actually, Roger's question came from a
>> discussion we'd had a few days ago.
>>
>> Following this thread I think I'll just implement the following
>> interface in pfm-1.2.0:
>>
>>   pfm.start(arg1,arg2, ... , argN) { |arg1,arg2, ... , argN| ... }
>
> What about redefining fork?

Not opposed necessarily but start(...) is already a wrapper around
fork().  That's really the whole point of PFM -- to handle the sordid
details of fork()ing and wait()ing without letting the user in on the
little secrets of either -- while providing a high-level interface and
a set of callbacks to get start, wait, and finish states if so
desired.  :-)

The guts of start(...) for PFM 1.2 would look something like:

  def start(args = nil, &block)
      ... etc ...
      raise "blah ... \n" if ! block_given?
      pid = (! args.empty?) ? fork { block.call(args) } : fork { block.call() }
  end

Does what I'm going for make sense?

-- 
NP