asynchronous cancel vs calling pthread_exit in signal handler

I'm a newbie in MT programming and I've been reading PwPT about
cancelling the execution of a thread.

I'm writing a database application which calls some 3rd party library
to send SQL queries to the database but sometimes the database is not
responsive and I would like to interrupt the call. Sending a signal
doesn't interrupt the call every time so I would like to
cancel/terminate the thread (deferred cancel doesn't work either).

>From what I've read it seems that asynchronous cancel is definitely
something that I shouldn't use. but I came across a suggestion of
calling pthread_exit() in the signal handler, I wonder if that's just
as dangerous as using asynchronous cancel?

Any help is appreciated. Thanks in advance.

Dave wrote:
> I'm a newbie in MT programming and I've been reading PwPT about
> cancelling the execution of a thread.
>
> I'm writing a database application which calls some 3rd party library
> to send SQL queries to the database but sometimes the database is not
> responsive and I would like to interrupt the call. Sending a signal
> doesn't interrupt the call every time so I would like to
> cancel/terminate the thread (deferred cancel doesn't work either).
>
> From what I've read it seems that asynchronous cancel is definitely
> something that I shouldn't use. but I came across a suggestion of
> calling pthread_exit() in the signal handler, I wonder if that's just
> as dangerous as using asynchronous cancel?

I don't think any of the pthreads functions are safe to call in a
signal handler.  They're not listed in the table of signal-safe
functions in the latest version of SUS.  In any case exiting a
thread from a signal handler is liable to leave shared data in
an invalid state, just like asynchronous cancellation.

> Any help is appreciated. Thanks in advance.

--
Ben Hutchings
If the facts do not conform to your theory, they must be disposed of.

so what is the general rule?
(1) If I'm sure that the signal doesn't interrupt any
nonasync-signal-safe functions, can I call nonasync-signal-safe
function in the signal handler?

The example Marc Rochkind gave in this Advanced Unix Programming book
uses _exit instead of exit to terminate a process. So by saying leaving
shared data in invalid state what kind of shared data is being referred
to? If I used exit() instead _exit() to terminate a process in a signal
handler would that possibly cause the OS or other processes to exhibit
undefined behavior?

thanks

Ben Hutchings wrote:
[...]
> functions in the latest version of SUS.  In any case exiting a
> thread from a signal handler is liable to leave shared data in
> an invalid state, just like asynchronous cancellation.

Except that properly coded async regions take care of bringing
the shared state to a valid state using cancellation cleanup
handlers.

regards,
alexander.

Dave wrote:
> so what is the general rule?
> (1) If I'm sure that the signal doesn't interrupt any
> nonasync-signal-safe functions, can I call nonasync-signal-safe
> function in the signal handler?

I believe so.

> The example Marc Rochkind gave in this Advanced Unix Programming book
> uses _exit instead of exit to terminate a process.

This is allowed because _exit does only minimal cleanup of resources
shared between processes.  Signals never interrupt the critical
sections associated with management of such resources.  The same is
not true of per-process resources such as the malloc() heap and stdio
streams.

> So by saying leaving shared data in invalid state what kind of
> shared data is being referred to?

Aside from any data your program explicitly shares between threads,
there's the malloc() heap, stdio streams, locale information, the
dynamic linker's state, and many other things.

> If I used exit() instead _exit() to terminate a process in a signal
> handler would that possibly cause the OS or other processes to exhibit
> undefined behavior?

Not on a normal Unix system, unless the processes share memory.

--
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.

Alexander Terekhov wrote:
>
> Ben Hutchings wrote:
> [...] 
>
> Except that properly coded async regions take care of bringing
> the shared state to a valid state using cancellation cleanup
> handlers.

Right - but this doesn't seem to apply in the OP's situation.

Hello Dave.

> so what is the general rule?
> (1) If I'm sure that the signal doesn't interrupt any
> nonasync-signal-safe functions, can I call nonasync-signal-safe
> function in the signal handler?

quoted from Dave Butenhof:

<quote>
Technically, yes. But I wouldn't bet much on it, as it's hard to code
and hard to test. It may be satisfying on some level to know that the
reason your application fails is an IMPLEMENTATION bug rather than an
APPLICATION bug; but your application still doesn't work. ;-)

Furthermore, this guarantee helps you only if you know exactly what your
thread will be doing at every instant in time. That is, essentially,
that you're writing a monolithic embedded application and never calling
any outside code with any signal unmasked. If you use the C or C++
runtime or threads, for example, any time you spend in those libraries
is NOT safe against async signals; unless you have all your signals
masked on each call.
</quote>


Hope this help,
Loic.