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
