Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement process create time #33

Closed
giampaolo opened this issue May 23, 2014 · 13 comments
Closed

Implement process create time #33

giampaolo opened this issue May 23, 2014 · 13 comments

Comments

@giampaolo
Copy link
Owner

From billiej...@gmail.com on March 07, 2009 11:47:39

Implement a method to determine when a process has been started/created.
As for time.time(), it would make sense returning the time as a floating
point number expressed in seconds since the epoch, in UTC.

Original issue: http://code.google.com/p/psutil/issues/detail?id=33

@giampaolo
Copy link
Owner Author

From billiej...@gmail.com on March 08, 2009 21:32:30

Implemented on Windows as r232 .

Status: Started

@giampaolo
Copy link
Owner Author

From billiej...@gmail.com on March 09, 2009 07:26:03

Implemented on Linux as r236 .

@giampaolo
Copy link
Owner Author

From billiej...@gmail.com on March 09, 2009 11:48:32

A debate to decide what return for PID 0 is also needed.
I modeled Windows and Linux implementations to provisionally return 0.0 (year 1970)
for now.
Returning the system uptime could make more sense.

@giampaolo
Copy link
Owner Author

From jlo...@gmail.com on March 13, 2009 08:03:38

PID 0 is the kernel, so system uptime would make sense.

@giampaolo
Copy link
Owner Author

From billiej...@gmail.com on March 13, 2009 16:41:52

Modified special case in create_time to return system uptime for PID 0 on Windows and
Linux as r257 .

@giampaolo
Copy link
Owner Author

From jlo...@gmail.com on March 16, 2009 13:19:05

Just do document this somewhere aside from the SVN log, in order to return system
uptime as a number of seconds since the epoch we had quite the juggling match on
Python 2.6 due to this issue: http://bugs.python.org/issue3308 Apparently the time.h functions aren't able to be loaded properly when using MinGW
with Python 2.6 on Windows. To get around this I've implemented the calculation of
current time in seconds since the epoch using the Win32 API to get the current time
as a FILETIME struct and converting the value. This is all implemented in
get_system_uptime() using some code I found here: 
http://johnstewien.spaces.live.com/blog/cns!E6885DB5CEBABBC8!831.entry Tested the code and it's returning the correct value (same as time.time() on Windows)
for current time which we can then subtract system uptime seconds from in order to
get system uptime in epoch time.

Note that Python 2.5 works just fine with MinGW time.h functions due to different
version of the visual C++ libs etc. but for compatibility reasons we'll use this
approach to avoid any issues in various environments.

@giampaolo
Copy link
Owner Author

From billiej...@gmail.com on March 16, 2009 18:09:53

I created issue 39 to discuss about pid 0 special case implementation separately.

@giampaolo
Copy link
Owner Author

From billiej...@gmail.com on March 16, 2009 18:10:03

Blockedon: 39

@giampaolo
Copy link
Owner Author

From billiej...@gmail.com on March 17, 2009 09:18:29

Labels: Progress-3in4

@giampaolo
Copy link
Owner Author

From billiej...@gmail.com on March 20, 2009 12:21:55

Labels: -Progress-3in4 Progress-2in4

@giampaolo
Copy link
Owner Author

From billiej...@gmail.com on March 20, 2009 14:11:27

Implemented on OS X as r269 .

Labels: -Progress-2in4 Progress-3in4

@giampaolo
Copy link
Owner Author

From jlo...@gmail.com on March 20, 2009 14:16:46

Implemented on FreeBSD as r272

Status: Fixed
Labels: -Progress-3in4 Progress-4in4

@giampaolo
Copy link
Owner Author

From g.rodola on March 02, 2013 03:46:45

Updated csets after the SVN -> Mercurial migration: r232 == revision 
7dc906066c68 r236 == revision 4e4234ba4c30 r257 == revision 442aee762cf4 r269 == revision 0c8ab44644c0 r272 == revision 56a85a5d48e9

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant