re: We should all be forking

re: We should all be forking

[Christopher Cramer]

Jon Harrop:
> I believe the performance relies upon the Linux kernel lazily copying
> the process. Does OSX also do that? 

It's called copy-on-write and I would be surprised if OSX didn't also
do it.

The only way to start a new process is to fork, so even if you're just
running another program you fork first, and then replace the process
image with the new program with exec. If the fork had to copy the entire
process image before just throwing it away upon exec, I think Unix,
which is based around a philosophy of piping between multiple processes,
would have abandoned fork a long time ago. Then again, there is vfork,
so I guess they almost did abandon it at one point.

This method doesn't work well at all on Windows, as I understand
it.

BTW your code looks a lot nicer than mine. The |> is brilliant, I think.
I'm a little surprised you cut the speed in half without using select.
And looking at your code I just realized I have a bug in mine...

Re: [Caml-list] re: We should all be forking

[Eric Cooper]

On Tue, Jun 05, 2007 at 03:30:47PM -0700, Christopher Cramer wrote:
> If the fork had to copy the entire process image before just
> throwing it away upon exec, I think Unix, which is based around a
> philosophy of piping between multiple processes, would have
> abandoned fork a long time ago. Then again, there is vfork, so I
> guess they almost did abandon it at one point.

vfork was introduced in BSD Unix when support for page-based virtual
memory was added for the DEC VAX.  There was an earlier Bell Labs
port of Unix to the VAX that just mimicked the PDP-11's segment
registers.  In that scheme, I believe text segments were shared, so
that only the data segment had to be copied on fork, but copy-on-write
is the way to go on any architecture with page tables.

-- 
Eric Cooper             e c c @ c m u . e d u

Re: [Caml-list] re: We should all be forking

[Oliver Bandel]

On Tue, Jun 05, 2007 at 03:30:47PM -0700, Christopher Cramer wrote:
> Jon Harrop:
> > I believe the performance relies upon the Linux kernel lazily copying
> > the process. Does OSX also do that? 
> 
> It's called copy-on-write and I would be surprised if OSX didn't also
> do it.
> 
> The only way to start a new process is to fork, so even if you're just
> running another program you fork first, and then replace the process
> image with the new program with exec. If the fork had to copy the entire
> process image before just throwing it away upon exec, I think Unix,
> which is based around a philosophy of piping between multiple processes,
> would have abandoned fork a long time ago. Then again, there is vfork,
> so I guess they almost did abandon it at one point.
> 
[...]

vfork is only (!!!) for a fork-exec combination.

So, be aware: do not use vfork, if you don't exec right after it!


Ciao,
   Oliver

Re: [Caml-list] re: We should all be forking

[Shawn W.]

On Jun 6, 2007, at 2:28 AM, Oliver Bandel wrote:
>
> vfork is only (!!!) for a fork-exec combination.
>
> So, be aware: do not use vfork, if you don't exec right after it!
>

Don't use it even then! The only functions a vfork()ed child process  
can call are an exec*() one or _exit() (And then I think only execv()  
and execve() are safe). It can't return from the function vfork() was  
called in. It can't safely modify variables.

In other words, it can't do any error handling to speak of if the  
exec fails. Sure, it's faster than a fork() (Even on a OS that does  
copy-on-right memory pages -- which most modern ones do) because you  
don't copy process table structures.... but it's way too fragile when  
something goes wrong. Which will happen, sooner or later.

-- 
Shawn W.
shawnw@speakeasy.org