On Tue, Jun 26, 2012 at 8:13 PM, Michael Schwartz <[email protected]> wrote:
> 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. > That's the kind of thing i was looking for. e.g. sharing a stdout handle could be mildly problematic. Sharing an sqlite3 db file handle or a MySQL socket (it connects to a localhost socket file by default) could be even more-so. 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!). > That's all great information, thanks. (Mis)Interactions with internal JS VM state were always highest on my list of suspicious behaviour. i never personally saw problems with it, but i bailed out early on because of my complete uncertainty with what was happening in the VM. Looking back on the code[1] now, it was trivial to implement. i'll give this a whack in v8. http://spiderape.svn.sourceforge.net/viewvc/spiderape/plugins/SystemFuncs/system_funcs.cpp?revision=65&view=markup line 483 -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
