Kind of. The GC will not collect the object, but #close can still be used explicitly. 


The reason for this is a bit of an oddity due to how mysql_close() uses shutdown(). Normally in cleanup you'd want to free the related client memory and only call close(), which would release the fd reference but not disrupt its use in other processes.

But we don't own the cleanup routines: mysql_close() also calls shutdown(), disrupts all use of the client object and the related socket. Ideally libmysqlclient would supply a way to free the client struct and close the handle without calling shutdown(). But as best I can tell this isn't possible.

There are some mitigating factors here: This can't leak resources in a loop, it becomes a one-time cost of forking. Because mysql_close() calls shutdown(s, 2), the TCP connection will be fully terminated and cleaned up from the kernel state. And #close still does the job explicitly -- anyone writing a proper program is going to want to explicitly manage objects with non-memory resources anyway; relying on the GC to collect things like stale connections is problematic in and of itself.

The limitations in libmysqlclient make this process a bit dirty no matter what so long as inheriting descriptors occurs. FD_CLOEXEC is the only completely clean answer, and probably correct by default, though it's also functionally restrictive.