"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