On Jul 20, 2011, at 8:32 AM, Michel Verbraak wrote:
We use fork and not threads. So the problem is clear.
I should qualify my previous statement a bit; Using libzdb from several sub-processes at the same time should not a problem per se if each sub-process create its own connection pool. The problem arise if the main thread/process initialize libzdb and then call fork. I suspect this is what's happening. Pthread structures does work well with fork. Especially mutexes can be left in an inconsistent state. For instance, if a mutex was locked in the parent process when it forked, the mutex will continue to be locked in the child process and there is no way for the child to unlock the mutex since the owner is a non-existing thread. ConnectionPool_free will lock the pool before it drains it and if the mutex is in an inconsistent state, calling ConnectionPool_free will typically hang on mutex lock and therefor never return.
We should be able to set libzdb in a proper state for a child process by using pthread_atfork(), but until we decide to implement this; if each sub-process create its own connection pool using ConnectionPool_new you should be fine.
Jan-Henrik