Many Thanks....
----- Original Message -----
From: "Jan Hudec" <bulb@ucw.cz>
To: "venugopal panchamukhi" <p_venu@delhi.tcs.co.in>;
<kernelnewbies@nl.linux.org>
Sent: Friday, May 31, 2002 11:17 AM
Subject: Re: how to add signal handler to kernel thread?
> On Fri, May 31, 2002 at 10:52:48AM +0100, venugopal panchamukhi wrote:
> > Hi,
> > Is it necessary for me to make the kernel thread sleep in
> > TASK_INTERRUPTIBLE state? If I don't do it, doesn't the task gets
scheduled
>
> A task is scheduled if and only if it happens to be in TASK_RUNNING.
> If task is in TASK_UNINTERRUPTIBLE, it's state can be modified only
> explicitly (usualy by waking up some waitqueue). If it's in
> TASK_INTERRUPTIBLE, it's put in running state when it gets a signal in
> addition to other options.
>
> Oh, of course if the thread is still in RUNNING state, it gets scheduled
> and signals get delivered (but you must still check for them when you
> emerge from schedule ofcourse).
>
> > (I know kernel threads are not preemptive).
> > My sample code is as mentioned below
> > 1. kernel thread is created by calling
> > kernel_thread(launch thread function, it's arguments, 0)
> > 2. launch_thread_func() will actually call the function which executes
as a
> > thread like
> > launch_thread_func()
> > {
> > kernel thread initiailization things...
> > ....
> > call thread_func() here...
> > }
> > void thread_func(void *)
> > {
> > ....
> > }
> > Now my question is, if I have to check for the signal asynchronously it
> > would be difficult as thread_func() could be a infinite loop.
> > If I have to check for the signals in current->signal or
current->blocked
> > then it wouldn't give a totally asynchronous way of checking the
signals.
> > This method is sort of polling, if i'm not wrong.
> > Doesn't the kernel provide any routine which lies in kernel and which
works
> > like sigaction() - without the need to change from user context to
kernel
> > context and vice versa.
>
> I always thought, that asynchronous handling is the one in userland and
> polling is called "synchronous".
> Anyway, the thread_func will do polling anyway. I still don't know what
> it shoud do, byt generaly the thread sleeps on some queue waiting for
> events it should handle ad if one comes, handles it and goes back to
> sleep. So adding a check for current->signals is trivial then.
>
> Oh, thread which does not go to sleep is a bad idea. And if you wanted
> to use longjmp to break a loop that's bad, bad, worse idea (The cleanup
> tends to get complicated if there are many ways out).
>
> --------------------------------------------------------------------------
------
> - Jan Hudec `Bulb' <bulb@ucw.cz>
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
