From: Brian Candler Date: 2003-03-07T22:12:16+09:00 Subject: Re: DRB and threads On Fri, Mar 07, 2003 at 07:15:29PM +0900, Robert Klemme wrote: > > If I understand this rightly, then I can't see how you can use this with > any > > object which carries state unless you rewrite or wrap all the methods to > > make them thread-safe. Is this correct? > > Yes, that's correct. Since the server can hand the instance's reference to > multiple clients (or a single multithreaded client) you must take measures > to handle this. OK, that's good to know; it could probably do with making clear in the documentation, since Bad Things will likely happen if you take an arbitrary object (like a DBI::DatabaseHandle) and share it via DRb! I did find references to a pool in the source (Class DRbConn), however it looks like it's for a client to have a pool of connections to multiple remote URIs, rather than a server having a pool of objects to handle requests. > Then I suggest to use a variation of the facade pattern: You have a single > instance that is known to clients. This instance internally holds a pool > of instances that do the real work. Methods of your facade fetch an > instance from the pool hand the request over to this, return the results > and put the instance back into the pool. Pool access must be synchronized > of course. I was thinking along the same lines. I guess it shouldn't be too hard to code, but it's unusual in Ruby to find something generic like this not already implemented :-) > > Another solution would be if I could run a DRb server under FastCGI, so > that > > I had a pool of processes (maintained by Apache) and requests would be > > farmed out to those processes. Is that possible? > > Possibly. Although multiple threads should be more efficient than multiple > processes. I'd actually like to run as multiple processes, for two specific reasons: (1) being able to avoid any blocking issues with DBI drivers. There will be some long-duration queries which take place; I don't want all other clients to block while this happens! (2) making use of multiple CPUs I quite like the Apache/FastCGI approach because the code for allocating instances of the backend is already written and hopefully reasonably debugged; it can have a fixed or variable number of instances. I guess I could write a front-end in Ruby and use IO.popen('-') to spawn children connected via a pipe. But then I'd want a version of DRb which sends messages over an IO object (and can respawn them if they die) Regards, Brian.