Resolving #180. I don't think this is a safe assumption to make about client libraries, since close doesn't necessarily only affect process-specific state. Sometimes the fork parent may intend to use that connection again and the forked child ends up breaking it (e.g. Dalli clients and Puma's fork_worker), so the parent still has the connection in the pool but its remote state is invalid. If the parent forks twice, it's also reliant on the client to not just implement close, but to do it in idempotent fashion so the second child doesn't blow up trying to close an already-closed connection. The state of a connection object post-fork seems best left to the connection library itself; the pool does enough by just removing whatever connections there are from the pool so the forked child cannot check them out.
Resolving #180. I don't think this is a safe assumption to make about client libraries, since
closedoesn't necessarily only affect process-specific state. Sometimes the fork parent may intend to use that connection again and the forked child ends up breaking it (e.g. Dalli clients and Puma's fork_worker), so the parent still has the connection in the pool but its remote state is invalid. If the parent forks twice, it's also reliant on the client to not just implementclose, but to do it in idempotent fashion so the second child doesn't blow up trying to close an already-closed connection. The state of a connection object post-fork seems best left to the connection library itself; the pool does enough by just removing whatever connections there are from the pool so the forked child cannot check them out.