Hi,

I know this is pretty common asked question, however am not able to
find the exact scenario that Im pondering on. The question as follow:

Is it 'okay' if an async-signal-unsafe function is called from signal
handler provided this function is never called from operation mode
within the thread? The actual functions that Im interested on are
sem_wait() and phtread_kill() (both are not in POSIX async-signal-safe
list). ('okay' as in - I know it may be not guranteed to work
flawlessly but i could live with something pretty low possiblity to
cause issues.)

http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html#tag_02_04_02
Says that "when a signal interrupts an unsafe function and the signal-
catching function calls an unsafe function, the behavior is
undefined."

>From here, it could even mean that the application could hang/crash
etc not just limited to the exact interrupted function called again in
signal handler but also any unsafe function. i.e A set of functions
may share same resources e.g synchronization objects - which
completely implementation dependent.

If the above statement is true - any comment for sem_wait() and
pthread_kill() behaviours especially for the following platforms:
1) Solaris 10
2) HP 11.11
3) Tru64 V5.1

ps: This is related to async signal handling, therefore sigwaitinfo()
etc are out of question and I also aware its good to let default
handling for async sigs (coredump), but this is not what am looking
for.

TIA,
Ravi Nallappan

Vanquish wrote:
> 
> I know this is pretty common asked question, however am not able to
> find the exact scenario that Im pondering on. The question as follow:
> 
> Is it 'okay' if an async-signal-unsafe function is called from signal
> handler provided this function is never called from operation mode
> within the thread? The actual functions that Im interested on are
> sem_wait() and phtread_kill() (both are not in POSIX async-signal-safe
> list). ('okay' as in - I know it may be not guranteed to work
> flawlessly but i could live with something pretty low possiblity to
> cause issues.)

TECHNICALLY, you've correctly stated the actual restrictions. Almost. It 
is OK to call non-async-signal-safe functions in a signal handler if and 
only if you can be absolutely sure that not only that function but all 
"co-dependent" functions that intimately share data are never called 
from non-signal code. That's why the text refers to "another unsafe 
function"; because the data dependencies may be obscure and widely 
spread. For example, it's obviously not OK to call malloc() in a signal 
handler if non-signal code calls malloc(); but you'll have just as much 
of a problem if non-signal code calls free(), or realloc(). In theory if 
you know that no malloc-FAMILY code is called at non-signal level when 
the signal occurs, you'd be OK.

There's a problem with this, however, because in a normal OS environment 
you cannot ever know that. For example, what if the C or C++ runtime 
uses sem_wait()? Or, as in the case of malloc(), a closely related 
function that might share user-mode data. sem_wait() MIGHT be a syscall, 
and often is... but POSIX doesn't require that, and it could be 
implemented in user-mode, in which case it would probably use thread 
library data -- and locks -- and would conflict with normal thread 
scheduling operations that are completely beyond your control. The same 
obviously goes for pthread_kill(), only more so since it's obviously 
quite closely tied to thread scheduling.

> http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html#tag_02_04_02
> Says that "when a signal interrupts an unsafe function and the signal-
> catching function calls an unsafe function, the behavior is
> undefined."
> 
>>From here, it could even mean that the application could hang/crash
> etc not just limited to the exact interrupted function called again in
> signal handler but also any unsafe function. i.e A set of functions
> may share same resources e.g synchronization objects - which
> completely implementation dependent.

Correct.

> If the above statement is true - any comment for sem_wait() and
> pthread_kill() behaviours especially for the following platforms:
> 1) Solaris 10
> 2) HP 11.11
> 3) Tru64 V5.1

HP-UX and Tru64 both support user-level thread scheduling, though the 
implementation is vastly different. On Tru64 you'd be on shaky ground 
with pthread_kill() because it's mostly user-mode, while sem_wait() is a 
syscall. I have no idea about HP-UX, but it doesn't sound like a safe 
bet to me. Solaris 10 has dropped user-mode scheduling, but I don't know 
that necessarily makes either function a direct syscall.

> ps: This is related to async signal handling, therefore sigwaitinfo()
> etc are out of question and I also aware its good to let default
> handling for async sigs (coredump), but this is not what am looking
> for.

Perhaps... but you really ought to find a way to redefine the problem so 
that it IS what you're looking for. ;-)

"Vanquish" <nkravi@hotmail.com> wrote in message 
news:1182955310.075388.252270@d30g2000prg.googlegroups.com...
> Hi,
>
> I know this is pretty common asked question, however am not able to
> find the exact scenario that Im pondering on. The question as follow:
>
> Is it 'okay' if an async-signal-unsafe function is called from signal
> handler provided this function is never called from operation mode
> within the thread? The actual functions that Im interested on are
> sem_wait() and phtread_kill() (both are not in POSIX async-signal-safe
> list). ('okay' as in - I know it may be not guranteed to work
> flawlessly but i could live with something pretty low possiblity to
> cause issues.)
[...]

What are you trying to accomplish? There are some pretty nifty things that 
can be done in signal handlers, but I need some more info on what your 
goal(s) are. I can't really think of why one would need to wait on a 
semaphore in a signal handler; humm...