kiranvizru / psutil

Automatically exported from code.google.com/p/psutil
Other
0 stars 0 forks source link

per-process status #143

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
This should be similar to STAT column of "ps aux" output and should return an 
integer or a (code, status_str) namedtuple reflecting the current process 
status (running, sleeping, etc...). On Linux this is available via /proc, as 
always, and the code->name mapping can be taken from fs/proc/array.c in the 
Linux kernel source code.
http://www.takatan.net/lxr/source/fs/proc/array.c#L129

On FreeBSD we can use kinfo_proc, as always, but I'm still not sure where to 
take the name mappings.
http://fxr.watson.org/fxr/source/sys/user.h#L110

No Idea about OSX and Windows. I'm cc-ing wj32.64 in case he knows something 
about Windows.

Either we choose to return an integer or a nametuple, it probably makes sense 
to expose constants such as psutil.PROC_STATUS_RUNNING, 
psutil.PROC_STATUS_STOPPED, etc. as well.

Original issue reported on code.google.com by g.rodola on 27 Dec 2010 at 2:34

GoogleCodeExporter commented 9 years ago
First draft for Linux and BSD committed as r871 and r872.

It seems there's no concept of "process status" on Windows. 
We got threads instead, and a thread can be either in a "suspended" or 
"resumed"/"running" state.
I think we can say that a process can be either in a "running" or "suspended" 
state depending on the status of its threads.

Perhaps we might assume that a process is in a "suspended" state if one of its 
threads is supsended, else we can assume it's "running".
There's no API to easily determine such a thing but here are some suggestions:
http://stackoverflow.com/questions/1006691/how-to-check-if-a-win32-thread-is-run
ning-or-in-suspended-state

Still not sure whether this is worth the effort, though.

Original comment by g.rodola on 27 Dec 2010 at 5:46

GoogleCodeExporter commented 9 years ago
You can do this easily by calling NtQuerySystemInformation. If you don't mind, 
I would like to do a rewrite of a lot of the functions to use the undocumented 
functions, as they are far easier to work with than the public ones.

Original comment by wj32...@gmail.com on 27 Dec 2010 at 8:10

GoogleCodeExporter commented 9 years ago
It's ok as long as we do not drop mingw32 support and tests keep passing also 
on 64 bit platforms.
If you're going to rewrite a lot of stuff it'b better if we split the work in 
separate tickets.

As for this specific feature feel free to provide a patch or just commit 
against the trunk (you have write access). As you want.

Is the assumption I made above correct btw? Does processes status on Windows 
work as I guessed?

Original comment by g.rodola on 27 Dec 2010 at 8:30

GoogleCodeExporter commented 9 years ago
Yes, that's correct. I don't have MinGW so I can't test the support for it. So 
maybe I won't do the rewrite...

Original comment by wj32...@gmail.com on 31 Dec 2010 at 4:18

GoogleCodeExporter commented 9 years ago
Some Windows instructions:
http://vtopan.wordpress.com/2009/04/15/how-to-find-out-if-a-threadprocess-is-sus
pended-get-thread-state/

Original comment by g.rodola on 15 Feb 2011 at 11:38

GoogleCodeExporter commented 9 years ago
Implemented on OSX in r917.

Original comment by g.rodola on 17 Feb 2011 at 10:33

GoogleCodeExporter commented 9 years ago
Implemented on Windows in r930.
Thanks to wj32.64 for the help.

Original comment by g.rodola on 22 Feb 2011 at 3:48

GoogleCodeExporter commented 9 years ago

Original comment by g.rodola on 28 Feb 2011 at 9:56

GoogleCodeExporter commented 9 years ago

Original comment by g.rodola on 20 Mar 2011 at 9:55

GoogleCodeExporter commented 9 years ago

Original comment by g.rodola on 9 Jun 2011 at 10:33

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Updated csets after the SVN -> Mercurial migration:
r871 == revision 0ce06bfb58fe
r917 == revision 0a9131af50cc
r930 == revision 2c1fe1a56d95

Original comment by g.rodola on 2 Mar 2013 at 11:57