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/
