Add Process.cpu - figure out what CPU a process is on

[GoogleCodeExporter]

Now that we have per-cpu related functions (see issue 125) it makes sense to 
add a new "cpu" property to Process class returning what CPU the process is 
currently running on.

Example:

>>> p = psutil.Process(os.getpid())
>>> p.cpu
0
>>>

This can then be used in conjunction with psutil.cpu_percent(percpu=True) as 
such:

>>> psutil.cpu_percent(percpu=True)
[1.1, 2.2, 3.3]
>>> psutil.cpu_percent(percpu=True)[p.cpu]
1.1
>>>

This is easy to do on both Linux and *BSD systems.
I'm not sure about Windows.
wj32.64, any idea?

Original issue reported on code.google.com by g.rodola on 11 Jul 2011 at 12:49

[GoogleCodeExporter]

Hmm, this is interesting.

1. There's no such thing as the current CPU for a process - a process doesn't 
run code. Its threads do.
2. 99.99% of the time it doesn't make sense to say a thread is running on a 
particular CPU, because almost all threads are sleeping 99.99% of the time. 
Perhaps you're referring to the affinity mask of a process/thread?

(There's the NtGetCurrentProcessorNumber() system call and 
RtlGetCurrentProcessorNumber(), but they only return information for the 
current thread, for obvious reasons.)

Original comment by wj32...@gmail.com on 11 Jul 2011 at 12:58

[GoogleCodeExporter]

As I suspected... 
I'm not familiar with windows thread concepts. 
Does exist a concept of "main process thread"? If possible we can return what 
CPU that thread is running on, otherwise we're gonna make this feature 
POSIX-only.

Original comment by g.rodola on 11 Jul 2011 at 1:15

[GoogleCodeExporter]

No, there is no "main thread" for a process. But that wasn't my main point. It 
was that the concept of "what CPU that thread is running on" doesn't make 
sense, because most threads aren't running most of the time. This would be the 
case in both POSIX systems and Windows systems, so maybe I'm not understanding 
this feature correctly?

Original comment by wj32...@gmail.com on 11 Jul 2011 at 1:18

[GoogleCodeExporter]

Imagine a resource intensive process such as:

while True:
   pass  # do nothing, just busy loop

This will hog the resources of a single CPU (100 % usage).
This feature is for figuring out *which* CPU is "serving" that process (and 
obviously it makes sense on multi core systems only).
Personally I don't know why one would want to know this information but I see 
it is available on all POSIX platforms and as such I'd like to make it 
available.

Original comment by g.rodola on 11 Jul 2011 at 1:26

[GoogleCodeExporter]

Well such a feature would be highly unreliable because even though that thread 
is consuming "100%" CPU, the CPU still may be running a different thread at the 
moment you try to check. I don't think you can do this for Windows (or any OS, 
even though you say POSIX has this).

Original comment by wj32...@gmail.com on 11 Jul 2011 at 1:34

[GoogleCodeExporter]

Well, this already applies to all aspects of Process class itself.
For example, you can instantiate Process with a certain PID then by the time 
you call one of its methods the process may be gone in meantime.

Original comment by g.rodola on 12 Jul 2011 at 11:47

[GoogleCodeExporter]

It seems we cannot retrieve this info on OSX.
Since I do not want do implement this feature on 2 platforms out of 4 I think 
it's better we give up on this for now.
Linux and FreeBSD implementation were added as r1103 and r1104 and reverted in 
r1106.

Original comment by g.rodola on 14 Jul 2011 at 9:33

• Changed state: WontFix
• Removed labels: Milestone-0.3.1

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Updated csets after the SVN -> Mercurial migration:
r1103 == revision 3d04c71f8886

Original comment by g.rodola on 2 Mar 2013 at 12:02