Hi everyone. I have this big problem. Im using db2 through CLI API in a (linux) multiprocess program (that also uses multithreading). The problem begins when the main program forks 3 o 4 processes that try to connect independetly to db2 calling the SQLConnect() function. Im not sure why, but eventually all the processes except one stay locked after calling that function. I used gdb tool to see whats going on on such processes, and I found out that all of them are locked on a pthread_mutex.
I know the description is somehow general to give exact solutions, but do you have any idea what could be wrong? Are the processes waiting for the server to response?
Ive solved my problem. The thing is that i was executing code after the fork() call with out doing any exec() (in particular, db2 cli api calls). That caused problems with the threads that are embedded in the db2 library. According to the linux documentation, its not advisable to do a fork() without an exec() when using multithreading libraries (basically, the status variables of the mulitithreaded library are inconsistent in the child thread, this includes mutex variable that the library might have created). So now I changed to to an exec() asap after the fork() calling a complete new program.
frusconi, thanks for your reply. but as far as im concerned, db2 cli DOES support mulitthreading by default (say, it initializes different contexts so api calls are thread-safe).