Potential race in poolboy:stop

[xinhaoyuan]

I found this when playing with the testing code using my in-house concurrency testing tool (will be released soon!).

poolboy:stop/1 is implemented using gen_server:call/2, which would return to the caller before releasing registered name (I confirmed in the gen_server code). Thus the testing code could be flaky due to failure of new_pool/2, when it's called after poolboy:stop returned but before the process is really killed.

In realistic usage, I think it would cause failure if someone wants to restart a named pool using poolboy:stop. A better way of terminating a gen_server would be using gen_server:stop/1 (which will wait for the process to really end).

BTW, there is also a flaky test of reuses_waiting_monitor_on_worker_exit, the test would fail if get_monitors(Pool) is called after Self ! {worker, Worker} in the inner process, but before poolboy:checkout(Pool).