Sharing the bound (see bind() ) socket with the child processes is pretty awesome for pre-fork servers.
The SilkJS HTTP server provides a hook, HttpChild.onStart. If you point that at a function, it will be called when a child is forked. That's where you'd open a MySQL connection, a SQLite3 DB, etc. The connection lives as long as the child. You probably don't want to share those connections anyhow, except for some connection pooling scheme. I found that if I created a MySQL connection in the parent and use it in the child processes, I get "server has gone away errors." http://dev.mysql.com/doc/refman/5.0/en/gone-away.html "You can also encounter this error with applications that fork child processes, all of which try to use the same connection to the MySQL server. This can be avoided by using a separate connection for each child process." Plus, I'd think that socket would become a significant bottleneck, since you'd be talking basically to a single thread in the MySQL server... On Jun 26, 2012, at 11:19 AM, Stephan Beal wrote: > 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 -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
