From: Joel VanderWerf <vjoel@...>
Date: 2007-04-06T03:54:08+09:00
Subject: Re: Forking and copying variables

Gary Wright wrote:
> 
> On Apr 5, 2007, at 12:19 AM, Joel VanderWerf wrote:
>> Are you using the win32/process version of fork? If so, what you are 
>> seeing is one of the differences between that and native fork on 
>> unix/linux.
>>
>> For example, this code:
>>
>>   puts "foop"
>>
>>   Process.fork do
>>     puts "fork"
>>   end
>>
>> on linux produces the following output:
>>
>> foop
>> fork
>>
>> and on windows (requiring 'win32/process' first) produces:
>>
>> foop
>> foop
>> fork
> 
> 
> This seems like a typical IO buffering problem rather than
> different semantics regarding process data shared across
> forks.
> 
> It looks like in the Windows version stdout is buffered such
> that 'foop' is not written before the fork.  After the fork
> the output buffer still has 'foop\n' in it.  At some point
> the parent flushes its buffer (with just 'foop\n') and then
> later the child flushes its buffer (with 'foop\nfork\n')
> giving you the result you see.
> 
> This is a common 'gotcha' in Unix if stdout is going to
> a file and so it isn't line buffered.  If stdout goes to
> a terminal device it is line buffered and so the problem
> doesn't occur since each call to puts flushes a line of
> output.
> 
> I'm not a Windows guy but that's what seems to be happening
> in Joel's example.
> 
> I'm still not sure what problem the original poster is
> encountering.  Some sample code and output would help.

The source for win32/process makes it clear what is going on:

       cmd = 'ruby -I "' + $LOAD_PATH.join(File::PATH_SEPARATOR) << '" "'
       cmd << File.expand_path($PROGRAM_NAME) << '" ' << ARGV.join(' ')
       cmd << ' child#' << @child_pids.length.to_s

       startinfo = [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
       startinfo = startinfo.pack('LLLLLLLLLLLLSSLLLL')
       procinfo  = [0,0,0,0].pack('LLLL')

       rv = CreateProcess(0, cmd, 0, 0, 1, 0, 0, 0, startinfo, procinfo)

It runs the same ruby script again in another process. It's not really 
fork in the unix sense.

-- 
        vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407