Re: Changing the state of a process

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Dec 25, 2005 at 01:20:17 -0800, Rajaram Suryanarayanan wrote:
> Jan Hudec <bulb@xxxxxx> wrote:  On Thu, Dec 22, 2005 at 22:41:48 -0800, Rajaram Suryanarayanan wrote:
> > > Also I try to change the state of the bash shell to -1 ( unrunnable ).
> > 
> > I see it in the comment, but that state does not seem to actually exist.
> > 
> > > I see that the current->parent->state is printed as 1 . I see that process
> > > state > 0 is stopped , as defined in "struct task_struct". Then why it is
> > > printed as 1 when the bash shell is actually running ?
> > 
> > No, it's not actually running. It's waiting for it's child to exit or be
> > stopped, inside wait syscall. State 1 is TASK_INTERRUPTIBLE.
> > 
> > > Also by changing the state of the bash shell to -1, I expected it to hang
> > > or something like that. But that did not happen. 
> > >
> > > Could anyone please let me know what is wrong with my approach..?
> > 
> > Don't use the numbers. Use the symbolic values TASK_RUNNING,
> > TASK_INTERRUPTIBLE, TASK_UNINTERRUPTIBLE and so on.
> > 
> > However, that's not the major problem. The major problem is, that it's only
> > permitted to alter your own state (that is set_current_state) except
> > well-defined case of waking up a process on a wait-queue.
>
> Thanks Jan for the informative reply.
>   Actually, I saw the definition of "struct task_struct" in the file include/linux/sched.h for the different states of the process. There it was -1 for unrunnable etc..
>    
>   struct task_struct {
>          volatile long state;    /* -1 unrunnable, 0 runnable, >0 stopped */
>          struct thread_info *thread_info;
>          atomic_t usage;
>          unsigned long flags;    /* per process flags, defined below */
>          unsigned long ptrace;

As I said, I did see that comment. It just seems to be plain wrong.

>   Can you please throw some light on how the kernel reacts when I try to
>   change the state of the parent process, ie not my own state..? Because
>   I do not see any error thrown up. How does kernel detect this ? 

It silently does nonsense. Basically the TASK_* macros are defined as
independent bits. This is used when the kernel needs to know whether process
is in any of a set of states (see eg. try_to_wake_up
<http://lxr.linux.no/source/kernel/sched.c#L985>) and uses bitwise end to
test it. And never actually checks that only one bit is set, because noone
does that.

>   Also I understand that bash shell is in TASK_INTERRUPTIBLE state, because
>   it is waiting for insmod to complete. If possible, pls tell me how it is
>   waken up by SIGCHLD signal when insmod completes.

It is waken up by any signal, because of being interruptible. It is waken by
child death or stopping because it waits on special wait-queue. Follow the
code down from sys_wait4. For the other signals, there is signal_wake_up in
kernel/signal.c, that is called when signal is queued for a process.

-- 
						 Jan 'Bulb' Hudec <bulb@xxxxxx>

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux