Re: DRB and threads

Brian Candler wrote:

>I wonder if anyone can give me some hints on the interactions between dRuby
>(drb) and threads.
>
>I have been having a bit of a play, and it seems if you set up a dRuby
>server in the way described in the Pickaxe, then each incoming request is
>handled as a separate thread, but method calls are made to the *same*
>object concurrently.
>
>[snip]
>
>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? Unfortunately I can't find much
>documentation in English, and I can't see if there's another way of running
>it - even simple serialisation, so that method calls are handled one at a
>time.
>
I highly recommend Pragmatic Programmers' book chapter on threads and 
synchronization:
http://www.rubycentral.com/book/tut_threads.html

The short answer is, no, druby does not by itself provide any 
synchronization or mutual exclusion for multiple threads accessing the 
same remote or local object.

>Anyway, the pattern I really want to implement is a pool of objects, with
>the method call handed to any free object (and that object does not get
>another request until it has finished handling the first one).
>
>The aplication is that I have a database front-end class where each instance
>keeps a DBI handle open (amongst other things) but each method call is
>independent of the previous one, i.e. there's no state kept
>*between* calls, other than inside the database itself of course. So
>incoming requests can be farmed off to any object which is free.
>
>Do I have to write a wrapper object which duplicates every method in my
>database class (or method_missing)? Or is there a simpler way of handling
>this?
>
Adding thread-safe synchronization primitives to your database frontend 
is probably a good idea anyway, but yes, this is probably the best way 
to go. Check out 'DelegateClass' in the standard 'delegate.rb' library 
file if you want a quick way to wrap only those methods that require 
synchronization, while passing all the other calls to the original object.

Personally, I'm somewhat surprised that there isn't an "object pool" or 
"worker thread pool" pattern implementation included in the standard 
pattern libraries...it seems like it wouldn't be too complex, and a 
standard thread pool design could speed up a lot of prototyping and 
tutorial tasks, even if it needed to be tuned for specific applications.

Hmm...I guess I just volunteered to write one, since I'm not finding 
anything on RAA... ;)

>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?
>
You could also maintain this pool the same way that you do a set of 
threads, and have each process implement its own druby server object 
which would be load-balanced by a single front-end. That approach would 
have the benefit of protecting you from any blocking calls that 
otherwise wouldn't be effectively avoided by the Ruby intepreter's 
non-native threads. Unfortunately, it also adds an additional layer of 
marshalling/unmarshalling overhead.

>
>Thanks,
>
>Brian.
>
>[P.S. I am using dRuby-2.0.2 with ruby-1.6.8]
>  
>

Good luck,

Lennon Day-Reynolds
[e-mail]