"Brian Candler" <B.Candler / pobox.com> schrieb im Newsbeitrag news:20030311234504.GA51909 / uk.tiscali.com... > I'd be interested in any comments on the attached solution (especially flaws > that I've overlooked); if it is sound then I'll stick it up on the Wiki. Great work! Things I like: Using a block as factory. Things I don't understand: Why do you introduce method alive? Are there conditions under which an instance in the pool can die? If not, you could check sanity when you take back an instance and put it into the pool. Why do you rededine the set of methods to invoke method_missing? This happens anyway if a method is not implemented. Room for improvement: I'd change the design in a way that the pool and the facade are separated. This is orthogonal functionality and by extracting the pool functionality to another class the design becomes cleaner and more modular, hence improved reusability. The @poolnotempty.wait(@mutex) should be in a loop because with only one element in the pool and two threads waiting and both are signalled only one can fetch the element and the other has to continue waiting. Normally this can't occur in your example, but there might be other signals sent via the same mutex; it saver to recheck the condition. You can look at some stuff I put here for threading purposes: http://www.rubygarden.org/ruby?MultiThreading Kind regards robert