questions on threads + signals

questions on threads + signals

Post by Alex Farbe » Thu, 30 Mar 2000 04:00:00



Hi,

I am using Debian Potato GNU/Linux and have a program with
2 threads: one is running readline and the other calls the
embedded Python. I would like to handle CTRL-C so, that if
readline is waiting for input (that is readline() is called),
it deletes the entered line, and if Python is running some
longer job (the thread with readline is locked on a mutex at
this moment) - I post KeyboardInterruptException to it.

However I have problems already to install an empty SIGINT
handler (via sigaction) which does nothin and calls return 0 -
it crashes. It seems to me, that both threads receive that
signal, is it correct? I also tried to call pthread_self()
in the signal handler to determine, for which thread it is
called, but I get the SIGSEGV. Is it safe to call pthread_self()
from signal handlers?

The threads FAQ suggests to create a thread for explicit
signal handling and calling sigwait in a loop. The signals
should be blocked on all threads. I haven't tried it yet.
What happens actually to the blocked signals? Are the pending
somewhere or are they lost? If pending, who gets them on
thread/program exit?

And my last question is: is it possible to see from the signal
handler, which function is currently called? It would be help-
ful to me to know that the readline() or that the PyEval_EvalCode()
is currently on stack. I am asking, because:

   readline_is_running = 1;              /* SIGINT here! */
   line = readline (prompt);
   readline_is_running = 0;

looks not so good to me - a SIGINT could occur between the first
and the second lines. Thank you for any comments/suggestions.

Regards
Alex

 
 
 

questions on threads + signals

Post by Kaz Kylhe » Thu, 30 Mar 2000 04:00:00



>However I have problems already to install an empty SIGINT
>handler (via sigaction) which does nothin and calls return 0 -
>it crashes. It seems to me, that both threads receive that
>signal, is it correct? I also tried to call pthread_self()
>in the signal handler to determine, for which thread it is
>called, but I get the SIGSEGV. Is it safe to call pthread_self()
>from signal handlers?

Absolutely not. Where did you get the idea that it is? The pthread_* functions
are not required by POSIX to be async safe.

Quote:>The threads FAQ suggests to create a thread for explicit
>signal handling and calling sigwait in a loop. The signals
>should be blocked on all threads. I haven't tried it yet.

This is the portable advice. On systems that implement threads ``properly'' a
signal that is delivered to the process as a whole will go to one of the
threads. The thread is selected arbitrarily from among those which have
it unblocked.

Quote:>What happens actually to the blocked signals? Are the pending
>somewhere or are they lost? If pending, who gets them on
>thread/program exit?

Any undelivered signals are simply discarded when a process or thread
terminates.

The interaction between signals and threads is somewhat different in Linux; you
should read the LinuxThreads FAQ.

--
#exclude <windows.h>