On Jul 20, 2011, at 3:57 PM, Michel Verbraak wrote:
We cannot let each child process create it's own pool because the main process is a listening server and on a new connection a fork is done.
A child process duplicates the image of the parent process at fork time so the child process will have its own connection pool whether you want it to or not. Or rather, it will have a copy of the parents connection pool at fork time. And since ConnectionPool_free hangs, the pool is probably in an inconsistently state. So, given that your child processes will have its own pool anyway, it is better to make sure that the pool they have works correctly. This is done by moving the Connection Pool creation and initialization code to the code the child execute first after a fork. A simpler option, unless you must for some reason use sub-processes, is to replace sub-processes with threads. Libzdb is intended to be used and works great in a multi-threaded application.
If you don't want to change any code now, at least make sure that the connection pool is _not_ started with a reaper thread, because the reaper locks the pool before it runs, there is no guarantee that the thread does not run when a fork is done. Meaning, if the reaper runs at fork time, the child process will not be able to get connections from the pool because the mutex is locked when the child is created.
Jan-Henrik