From: Ken Bloom <kbloom@...>
Date: 2009-05-21T22:39:59+09:00
Subject: Re: mysql vs. fork

On Thu, 21 May 2009 08:43:55 +0900, Daniel DeLorme wrote:

> Ken Bloom wrote:
>> One solution is to encapsulate the database connection in a DRb server.
>> I have written about this in ruby-talk:296032 (see http://
>> blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/296032)
> 
> Hmm, in that message when you wrote that "DRb connections will work just
> fine across forks" did you mean that the parent's connection won't be
> closed when the child process exits? Because otherwise, I don't see how
> both parent and child could share a forked socket.
> 
> -Daniel

On UNIX, parent and child can *always* share a forked socket, and that's 
how pipes work in the first place. The question is whether the protocol 
is designed so that having two processes using the same end of the socket 
will do something sensible or not.

From my testing with DRb, they at least do something sensible regarding 
closing the socket -- the first process exiting doesn't tell server to 
shut down the connection on the second process. I'm not sure whether the 
protocol is still sensible when two processes are using it concurrently. 
If you keep following the chain of links back from the post I linked you 
to this time (and the other posts in those threads), then you'll see that 
I used this technique for recovering from a segfault in the child by 
respawning a new child. I don't guarantee that you could do something 
concurrent in the child.

What you *could* do is open a new DRb connection to the same server in 
the child and use that. Then you won't have concurrency issues in the DRb 
protocol, though you may need to find out how well the MySQL client in 
the DRb server can handle concurrency.

-- 
Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/