My team had to deal with something like this a couple years ago. Because of some external constraints on the implementation of our connection pool, we needed to emit events to a listener whenever a connection was returned to the pool, but we wanted to have the connection automatically checked back into the pool when dropped, and that required doing some async things. The "solution" we came up with was that checking the connection back in a short bit later was acceptable, so we just spawned an async task in the `Drop` implementation that would emit the event and check the connection back into the pool. Spawning an async task is fairly cheap, so the `drop` method would finish quickly, and the work needed to check the connection back in the pool was done in the background. The only tricky part was implementing the test suite, as part of the external constraint was that we had to verify our behavior with some tests expressed in an agnostic, declarative fashion which expected us to be able to assert that events happened in a deterministic order. In practice, adding a short yield to the runtime in the test harness between operations caused the async runtime to almost always return the connection to the pool with the spare time it had, and we reasoned that we could always increase the length of time the test executor yielded if we ended up having too many spurious failures.