From: "Ara.T.Howard" Date: 2005-08-11T23:43:23+09:00 Subject: Re: Threading on Win32 - at an impasse 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 ===============================================================================