Avoid draining pool in gardener cleanup

[wtn]

When a Sync scope exits while the gardener is waiting, Async::Cancel interrupts @condition.wait(@mutex) inside @mutex.synchronize, producing a ThreadError warning. The gardener's ensure also called self.close → drain, which could block if resources are still acquired during teardown.

warn: Async::Task: Async::Pool::Controller Gardener
  Task may have ended with unhandled exception.
    ThreadError: Attempt to unlock a mutex which is not locked
    → async-pool-0.11.2/lib/async/pool/controller.rb:132 in `synchronize'
    Caused by Async::Cancel: Task was cancelled

The gardener's ensure now force-retires resources directly instead of calling close/drain.

Types of Changes

• Bug fix.

Contribution

• I added tests for my changes.
• I tested my changes locally.
• I agree to the Developer's Certificate of Origin 1.1.

[samuel-williams-shopify]

Hmm, I'm not sure about this issue.

I could reproduce a hang:

Sync do
	policy = proc{|pool| pool.prune(0)}
	pool = Async::Pool::Controller.new(Async::Pool::Resource, policy: policy)
	
	# Acquire a resource (starts the gardener) but don't release it
	pool.acquire
	
	# Let gardener start and enter its wait loop
	sleep 0.05
end

But this program is malformed, since the resource is never released, that's an expected hang. The pool is designed to gracefully clean up. If you rewrite the program:

Sync do
	policy = proc{|pool| pool.prune(0)}
	pool = Async::Pool::Controller.new(Async::Pool::Resource, policy: policy)
	
	# Acquire a resource (starts the gardener) but don't release it
	pool.acquire do
		# Let gardener start and enter its wait loop
		sleep 0.05
	end
end

It does not hang.

I think it's better to have correct semantics and hang when the program is malformed. If there is a valid program that results in a hang, feel free to open a new issue.