Mike Kasick wrote:
>
> The one situation I'm working on right now is basically a pub/sub
> mechanism on top of drb.  Basically a bunch of clients register a
> callback object in a hash (keyed by some client identifier) on a server.
> When a message is published, it gets sent to each client registered in
> the hash.
>
>   

Seems you are implementing an MoM (Message oriented Middleware) on your own.

Threads may be a little overkill for such a system. I'm currently 
working on stompserver and the "topic" system  might be a good choice 
(depending on the constraints on you client side).

Basically, stompserver is a Ruby MoM based on the Stomp protocol. Each 
client connecting to a stompserver can:
-  publish in queues or topics,
- subscribe to queues or topics and listen for incoming messages.

On queues one message is delivered to one and only one client subscribed 
to the queue. On topics, the message is dispatched to each and every 
client subscribed. The whole server is based on EventMachine which used 
a simple select loop (with 0.8.0 they just switched to epoll on Linux 
but the idea is the same: one processus, one thread, event driven server).

As ruby currently doesn't support native threads, event based servers 
are probably the best fit to get performance (not to mention that often 
event based servers outperform thead based servers, especially on a 
single CPU system and sometimes even on SMP) and to avoid thread related 
complexity.

Stompserver isn't the only solution around. ReliableMessaging is another 
that might even be better suited to your needs as it is based on Drb 
too, see 
http://trac.labnotes.org/cgi-bin/trac.cgi/wiki/Ruby/ReliableMessaging

Lionel