>From the OSX man page for fork:
Fork() causes creation of a new process. The new process (child process)
is an exact copy of the calling process (parent process) except for the
following:
o The child process has a unique process ID.
o The child process has a different parent process ID (i.e., the
process ID of the parent process).
o The child process has its own copy of the parent's descriptors.
These descriptors reference the same underlying objects, so
that, for instance, file pointers in file objects are shared
between the child and the parent, so that an lseek(2) on a
descriptor in the child process can affect a subsequent read or
write by the parent. This descriptor copying is also used by
the shell to establish standard input and output for newly cre-
ated processes as well as to set up pipes.
o The child processes resource utilizations are set to 0; see
setrlimit(2).
Notably missing is that fork() does not clone any threads associated with the
parent process. I've been told by V8 committers that there are no threads
running of consequence to the child processes. I was initially concerned that
maybe some thread in v8 was doing the hot spot type optimization of the
generated machine code, but I'm told that this isn't done by a thread. Maybe
fork() loses some profiling information. Certainly fork loses the debugger; to
get around this, the -d flag to the httpd server tells it to not fork() but to
call the HttpChild's run function. You can fully debug with node-inspector
that way (works great!).
On Jun 26, 2012, at 10:55 AM, Stephan Beal wrote:
> On Tue, Jun 26, 2012 at 7:47 PM, Michael Schwartz <myk...@gmail.com> wrote:
> Something else I discovered early on in SilkJS development is that you can
> call from JS, a C++ function that calls fork() and returns. After the
> return, you have a parent and child process resuming in JS context. The
> child process is a literal clone of the parent, including the context and
> it's global and everything compiled in. So if you have a "pristine" global
> object set up by JS and call fork() for each request, you have a pristine
> global in the child
>
> Nice idea. To drag us off topic for a moment... i implemented fork() for
> SpiderMonkey some years ago but never really trusted that the JS engine would
> behave properly if forked, so i never used it. Does v8 provide any specific
> guarantees in the face of forking, or are you aware of any notable down-sides
> to using fork() from JS in generic client code?
>
> --
> ----- stephan beal
> http://wanderinghorse.net/home/stephan/
> http://gplus.to/sgbeal
>
>
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
