On Tue, Mar 11, 2003 at 10:03:53AM +0900, NAKAMURA, Hiroshi wrote:
> dRuby is from 'Distributed Ruby', and the author Seki-san
> intends to offer users to be able to move in-process Ruby
> environment to distributed Ruby environment easily.  No one
> expect
> 
>   s = Servant.new
>   5.times do
>     res = s.request
>   end
> 
> to do s.dup for each request.  So users who want mutex,
> ACL, name service, activation and etc which Ruby does not need,
> creates these by themself.

I wasn't expecting it to dup for each request, but I did at first expect the
requests to be serialized. I can see now why DRb's main_loop starts a fresh
thread for each connection: it lets it go back to accept() to get new
inbound connections. Also, because DRb TCP connections are persistent,
requests can come in on different sockets in an arbitary order. If it
serialized in the way I had imagined, it would have to keep an array of open
sockets and select() on them.

And of course, there are cases where the concurrent method-call behaviour is
desirable. You just have to be aware that it is happening... and that you
can't just serve up a 'normal' object (i.e. with instances variables not
protected by mutexes) without it breaking.

> # Fortunately there are many samples around dRuby.
> # Rinda::Ring as lightweight Jini, etc.

I'm afraid Java-specific terminology means nothing to me, that's one area
I've purposely kept clear of :-)

Regards,

Brian.