Historically the driver, when closing various objects and stopping background threads, did not wait for the threads to finish running prior to returning. In recent versions an argument was added to close/stop methods to wait for the background threads to terminate, which is off by default. The current situation of close/stop methods not waiting for background threads could cause the following issues:

1. Our forking guidance is to close clients before the fork. The default behavior of this close is to not wait for background threads. As a result, resources may not be cleaned up before the fork, and they may attempted to be cleaned up after the fork when the clients have potentially reconnected, thus using wrong client instances or failing.
2. It is awkward to reason about concurrent operations in the connection pool populator and SRV monitor in particular.
3. Although it is possible to request that close/stop wait for background threads, this not being the default behavior means it is easy to forget to request it and end up with the "async close".

Suggested change to the driver is to always wait for background threads to terminate when stopping them or closing objects that encapsulate background threads. 1885 covers changing higher level API to remove the close=false option from client/cluster/server.