On 20-07-11 14:27, Jan-Henrik Haukeland wrote:
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
To unsubscribe: http://www.tildeslash.com/mailman/listinfo/libzdb-general
Jan-Hendrik,
We create one pool in the main process before any fork is done. This pool is freed when the main process terminates. The main process sends a sigterm to all child processes when it receives a sigterm. The child process does an exit when it receives the sigterm.
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. Currently we do not use ConnectionPool_free because the whole process is ended on a sigterm and memory is released. It is dirty but works until we get our software right.
Regards,
Michel