Re: Signal delivery

[Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx>]

Hi
> Hi Mulyadi,
>     Thanks for your response.
No problem... however, I have pretty weak knowledge about signal 
handler, so you still must re-confirm it by reading any relevant Linux 
kernel books.

> I am still unclear about the signal handling mechanism of a kernel 
> thread.
> Assuming I manually unblock a particular signal, and also register a
> particular handler too with it. Now my doubt is at what time this 
> particular
> signal be handled, provided a) another kernel thread raise the signal for
> former thread, 
IIRC, sending signal implies rescheduling. After that, assuming the next 
running process is the target process, it should realize that there is 
pending signal in its signal queue.

But like I said (by briefly reading kernel thread handling codes and 
entry.S), kernel threads don't do the checking by default and most 
kernel threads running in our system don't do that. So, what you can do 
here is probably checking repeatedly for pending signal in a loop.

> b) some user process(if it can) raise the signal.

I think it's the same like (a) above.
> The doubt came in my mind, because kernel thread will never go to user
> space, hence it should be checking for the pending signals at some other
> time, question is when ?? Is it every time it gets scheduled ? or ???
I understand your doubt. It took me a while when browsing entry.S and 
(vaguely) understand this action.

May I ask, what kind of scenario you want to do via signal? Maybe we can 
suggest another alternative...

regards,

Mulyadi


--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ