signal handling in Threads

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
virusx

signal handling in Threads

Post 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
User avatar
Pype.Clicker
Member
Member
Posts: 5964
Joined: Wed Oct 18, 2006 2:31 am
Location: In a galaxy, far, far away
Contact:

Re:signal handling in Threads

Post 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.
virusx

Re:signal handling in Threads

Post by virusx »

Thanks,
Can you give some good links where i can find signal handling info on multithreading OS.

thanks
distantvoices
Member
Member
Posts: 1600
Joined: Wed Oct 18, 2006 11:59 am
Location: Vienna/Austria
Contact:

Re:signal handling in Threads

Post 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*
... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image
Post Reply