From: Bill Atkins <batkins57@...>
Date: 2005-08-11T23:55:41+09:00
Subject: Re: Threading on Win32 - at an impasse

There's a Process.fork in win32-process, but despite the name it does
not fork. :)

When you call Process.fork (the win32-process version), it will
re-execute everything leading up to the fork call.  From that point
on, the child process will execute the contents of the associated
block and the parent will continue after the block.

On UNIX, calling fork makes a copy of the program and all the data
associated with it in the process table.  So you get an identical
process created and control literally forks at the point of the fork
call - the child process does one thing and the parent does something
else.  UNIX fork does not re-run any code before that fork.

Technically, anything but UNIX fork is not really forking.  Microsoft
products don't have this concept at all; you can only create brand-new
processes.  I don't know of any real way to emulate forking without
access to the operating system itself, so Win32 users are probably
stuck as far as this goes.

Bill

On 8/11/05, Ara.T.Howard <Ara.T.Howard@noaa.gov> wrote:
> On Thu, 11 Aug 2005, Bill Atkins wrote:
> 
> > Sure.  This solution might not work for everyone, because fortunately
> > I don't really have to do much interprocess communication aside from
> > being able to start and stop children at will.  So I have a simulation
> > class:
> >
> > require 'win32/process'
> >
> > class Simulation
> >  .... blah blah blah
> >
> >  def start
> >    @pid = Process.run "ruby bin/run_device.rb #@dev_name #@name"
> >  end
> >
> >  def kill
> >    Process.kill 9, @pid if @pid
> >    @pid = nil
> >  end
> >
> >   .......blah blah blah
> > end
> >
> > And the bin/run_device.rb file loads up the appropriate simulation and
> > does its thing in the background.  run_device.rb is the important part
> > - it is more or less my answer to Win32's lack of fork; it loads the
> > library files it needs and then starts up the simulator, so it's as if
> > I've forked the process, but not really. :)  run_device.rb's code is
> > long and not too interesting (and application-dependent in any case),
> > so I won't post it here.
> >
> > Process.run is a custom function that Does The Right Thing based on
> > what OS the program is running on:
> >
> > module Process
> >  def self.run app
> >    if RUBY_PLATFORM =~ /win32/
> >      puts "calling create"
> >      Process.create :app_name => app
> >    else
> >      puts "calling fork"
> >      fork do
> >        exec app
> >      end
> >    end
> >  end
> > end
> >
> > If only Microsoft would implement fork/exec........
> >
> > Sigh.
> >
> > Hope that helps,
> 
> it does - there is a win32-fork - guess you can't exec then?  i don't really
> know the semantic difference between win fork and nix fork.
> 
> thanks alot for the example - i've faced this same issue before and gave up.
> ;-)
> 
> -a
> --
> ===============================================================================
> | email :: ara [dot] t [dot] howard [at] noaa [dot] gov
> | phone :: 303.497.6469
> | Your life dwells amoung the causes of death
> | Like a lamp standing in a strong breeze.  --Nagarjuna
> ===============================================================================
> 
> 
> 


-- 
Bill Atkins