Re: SIGPIPE in combination with Pro*C

Jeroen wrote:
>
> Question,
>
> I am (still) developing a Pro*C program (C++) that gets records from a
> database and updates records in a database. The program runs on DEC Unix
> v4.0d. It works the following way: The main thread puts its requests in a
> class (singleton) and wakes up the database thread (by setting a condition
> variable) . The mainthread goes to sleep (waiting for a condiction variable)
> OR waits for a specified time. The database thread wakes up, performs
> database access, makes the mainthread run (by setting the condition
> variable). And goes to sleep again. This is done this way because i do not
> want want the application to hang in case something goes wrong during db
> access. So for this all works fine.
>
> In case the connection fails, this mechanism only works once. Using the GDB
> (Gnu debugger) i see that somewhere in the Oracle library a write() function
> (probally write on a socket) raises a SIGPIPE. After that it seems that the
> whole application is hanging. I tried to ignore this signal but it doesnt
> help. Can somebody please help me out ?
>
> thanks in advance Jeroen

If the connection is broken (as evidenced by the "sigpipe") then you are going to have to re-establish the connection. Also, you have to be very careful about using signals (or linking to libraries that use signals) in threaded applications: unless you do it right, you can't predict which thread within your process will actually receive the signal for processing. Assuming your environment supports it and given the your current design (doing a timed wait on a condition variable), you probably
want to add another thread, just for processing signals, that sets a condition variable that your main thread can check when it wakes up due to a timeout on waiting for the db thread. Just make sure that all signals are blocked in your main & db threads, which ensures that only the thread you want to handle the signal receives it.

Hope this helps. Received on Tue Jul 17 2001 - 01:27:37 CDT