Signals and threads

[shibu-kundara]

Hi folks,
I have a problem using sigaction function in pthread library.
I have 2 thread each one registering

in threadA
act1.sa_handler=func1;
if(sigaction(SIGUSR1,&act1,NULL)) printf("\nSigaction failed! in th1
!!\n");

in threadB
act1.sa_handler=func2;
if(sigaction(SIGUSR1,&act2,NULL)) printf("\nSigaction failed! in th2
!!\n");

but when i send signal SIGUSR1 to threadA , threadA receives the
signal
but the handler func2 is getting called,

To solve this problem, i did some experiment in the kernel

In the pthread_library clone call is used , In the man page of clone
its given that
if CLONE_SIGHAND is not defined, the signal handlers will not be shared

between threads.
I recompiled the pthread library with out CLONE_SIGHAND .


I linked the program with the new library , It has been ok in the
do_fork call in the pthread funciton, A new struct of task_struct->sig
is allocated. Also i have seen that the sigaction function call in the
thread modifies and install a new handler in this already allocated
task_struct->sig structure.
Inspite of all this the last sig handler function is getting called
when i send the signal to the first thread. Any clue???


thanks
thomas

 

[mark_bluemel]

Inspite of all this the last sig handler function is getting called
when i send the signal to the first thread. Any clue???

yes. Try a group that concentrates on your context - threading on Linux
- rather than the language you've implemented in.
comp.programming.threads may be a good start.

 

[Mark McIntyre]

Hi folks,
I have a problem using sigaction function in pthread library.

unfortunately threads are offtopic in CLC as they're quite platform
specific and not part of hte C langauge (after all, threads can exist
in all languages). You will need to ask in a group specialising in
programming for your particular platform.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan