On Tue, Sep 18, 2012 at 9:32 AM, Amit Gupta <[email protected]> wrote:
> Hi All, > > I had a question about manipulating process state information in the > kernel and am curious about the right way to go about it. > (I'm just messing around with some stuff to try and understand the kernel > better). I had 2 questions: > > 1. I'm trying to create a process in the TASK_INTERRUPTIBLE state in the > kernel. Since do_fork() creates a process/task that is ready to be > scheduled, I was thinking what might be a good way to pull it off the > runqueue/stop its execution after do_fork() returns? > > Assuming you do the change in the do_fork() so that new process moves to sleep queue Whatever new process created made to TASK_INTERRUPTIBLE in the do fork, who will wakeup the new process. If you just type "ls" commnad also it does not work as ls command calls fork() + exec(). So your shell fork() and moves to sleep queue. Similarly lot of fork+exec activities happen in the system will all move to sleep queue. Many deamons running on the system may do fork() or fork + exec() will stop working. > 2.I'm curious if someone can explain the correct way to use the > "set_task_state()" macro. Its implementation just seems to boil down to an > assignment to the appropriate member of the task_struct. The question I had > in mind was, what if the process is already running? Is it safe to do it? > Don't we need to acquire some sort of lock before we manipulate a > task_struct ? > set_task_state() macro is used for portability reason. Earlier code shows direct manipulaation fo task_struct->state. When you execute wait_interruptile() family calls, it is the running process in kernel executes set_task_state() . > > 3. I would also be interested to read the correct way to use task_lock() > that locks on alloc_lock field of the task_struct. What exactly is this > lock for and does acquiring it/or any other lock in the task_struct cause > the process to be remoted from the runqueue? > > > Would appreciate any pointers to appropriate code/reading or any > explanation. > Thanks, > -- > Amit Gupta > > > _______________________________________________ > Kernelnewbies mailing list > [email protected] > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > >
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
