<?xml version="1.0" encoding="windows-1252"?>
<node id="930862" title="Re^3: Win32, fork and XS globals" created="2011-10-11 13:17:57" updated="2011-10-11 13:17:57">
<type id="11">
note</type>
<author id="171588">
BrowserUk</author>
<data>
<field name="doctext">
&lt;blockquote&gt;&lt;i&gt;&lt;/i&gt;&lt;/blockquote&gt;

&lt;p&gt;For a very large proportion of uses of [fork] -- essentially all those using the 'fork &amp; exec' idiom -- [system], especially &lt;c&gt;system 1, ...&lt;/c&gt; is a far more effective 'emulation'. The spawned process can (by default does) inherit many of the system resources -- open file, pipe and socket handles and the like -- that forked processes inherit under *nix.

&lt;p&gt;But, as [Corion] correctly points out, there are limitations that prevent it from being a transparent solution to porting [fork]ing programs to Windows.

&lt;p&gt;It is possible to provide a more realistic and efficient [fork] emulation on Windows -- one that uses real processes and even COW memory. Creating the new process and giving it COW access to the parents memory segments is relatively trivial. The difficult part is fixing up the perl internals within the spawned copy.

&lt;div class="pmsig"&gt;&lt;div class="pmsig-171588"&gt;
&lt;hr /&gt;
&lt;font size=1 &gt;
&lt;div&gt;Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.&lt;/div&gt;
&lt;div&gt;"Science is about questioning the status quo. Questioning authority". &lt;/div&gt;
&lt;div&gt;In the absence of evidence, opinion is indistinguishable from prejudice.&lt;/div&gt;
&lt;/font&gt;

&lt;/div&gt;&lt;/div&gt;</field>
<field name="root_node">
929097</field>
<field name="parent_node">
930816</field>
</data>
</node>
