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/