Page 1 of 1

signal handling in Threads

Posted: Sat Apr 10, 2004 11:47 pm
by virusx
Hi,
How can i implement signal handling in multithreading os.
1. What should i include in Thread control block.
2. More info on signal mask.

regards VirusX

Re:signal handling in Threads

Posted: Sun Apr 11, 2004 3:22 am
by Pype.Clicker
The question is what do you want as "signal handling" ?

I guess you want to have something compatible with Unix signals, right ? But multithreaded signals are a pain and usually lack of a clear semantic (when the signal SIG_ALRM is sent, which thread is to be notified ? Linux pushes the weirdness up to having threads belonging to the same process to have different ProcessID !)

Imho, you should better not try to emulate that "process signals" behaviour in a new kernel. Go for something that is inherently thread-based.
What should be added to the Thread Control Block ?
Basically an array of signal handlers (pointer to the function to be called plus a few extra :) and the mask
Can you tell me more about the mask
It works the same way as the PIC mask feature: when a signal #i is received, the ith bit of the mask is checked. If it's set, the signal can be delivered, if it's cleared, it cannot. The system then set a bit telling that signal #i is pending and the handler will be called as soon as an operation sets the #i bit in the mask again.

Re:signal handling in Threads

Posted: Sun Apr 11, 2004 5:20 am
by virusx
Thanks,
Can you give some good links where i can find signal handling info on multithreading OS.

thanks

Re:signal handling in Threads

Posted: Mon Apr 12, 2004 5:13 am
by distantvoices
I'll do a *per thread* signal handling.

The signal handling mechanism will be handled entirely by the micro kernel with extra system calls (not send nor receive). It is like with the semaphores: I don't want spend time with ugly message passing for such a "simple" thing like a dispatched signal.

I know, this is against the *pure* micro kernel philosophy. But is it really necessary to put signal handling into the mm service like Minix is doing? I think, this is no task for the memory management. *grmpf* but completely a kernel task.

Well, it is up to you to decide how you want to handle it. I just recommend: If you consider something too crucial to have it run via send/receive - introduce an additional trap for it. Semaphores for example I consider something way too crucial to have it be handled via message passing.

Stay safe. I know, my comment is kept vaguely. I'm myself on fleshing out the concept of signals in the depths of /dev/brain. This will take quite some time for unconscious threads are often preempted by consciousness. *gg*