python/psutil/TODO
author B2G Bumper Bot <release+b2gbumper@mozilla.com>
Mon, 17 Nov 2014 02:02:21 -0800
changeset 216076 04b37e14c1ec4e74ac1595b22f4bd80565df2bca
parent 144019 ed0b6a11532d2905ce3c5c55f230b0e89b8971dd
child 221256 697eb6db7d96dc21e817cd27a7e46ed4ab00f9bb
permissions -rw-r--r--
Bumping manifests a=b2g-bump

TODO
====

A collection of ideas and notes about stuff to implement in future versions.
"#NNN" occurrences refer to bug tracker issues at:
https://code.google.com/p/psutil/issues/list


HIGHER PRIORITY
===============

 * #387: system-wide connections (netstat).
 * OpenBSD support.

 * #371: CPU temperature (apparently OSX and Linux only; on Linux it requires
   lm-sensors lib).

 * #250: net ifaces speed.

 * (Linux) resource limit get/set - see man prlimit.

 * Process.name on Windows is slow:
   http://stackoverflow.com/questions/6587036/

 * Windows binary for Python 3.3 64-bit.

 * #269: expose network ifaces RX/TW queues.


LOWER PRIORITY
==============

 * #355: Android support.

 * #276: GNU/Hurd support.

 * NetBSD support?

 * DranflyBSD support?

 * AIX support?

 * examples/pidof.py (same as 'pidof' cli tool)

 * examples/pstree.py (same as 'pstree' cli tool)
    * get_threads() should also return thread names in order to implement it

 * examples/taskmgr-gui.py (using tk).

 * system-wide # open file descriptors:
    * https://jira.hyperic.com/browse/SIGAR-30
    * http://www.netadmintools.com/part295.html

 * Number of system threads.
    * Windows: http://msdn.microsoft.com/en-us/library/windows/desktop/ms684824(v=vs.85).aspx

 * #357: what CPU a process is on.

 * thread names:
    * https://code.google.com/p/plcrashreporter/issues/detail?id=65


DEBATABLE
=========

 * [Linux]: process cgroups (http://en.wikipedia.org/wiki/Cgroups). They look
   similar to prlimit() in terms of functionality but uglier (they should allow
   limiting per-process network IO resources though, which is great). Needs
   further reading.

 * cpu_percent(): current default interval is 0.1 so that by default it will
   produce a meaningful value. It represents a trap in case the user iterates
   over multiple processes though, as it introduces a big slowdown.
   Should it default to 0.0?

 * Rename connection ntuple's fields 'local_address', 'remote_address' to
   'laddr', 'raddr'  (note in accordance with http://bugs.python.org/issue17675)

 * Process per-cpus percent (XXX Windows only?), see:
   https://groups.google.com/forum/?fromgroups#!topic/psutil/ErrKTxAbu50

 * Should we expose OS constants (psutil.WINDOWS, psutil.OSX etc.)?

 * Python 3.3. exposed different sched.h functions:
   http://docs.python.org/dev/whatsnew/3.3.html#os
   http://bugs.python.org/issue12655
   http://docs.python.org/dev/library/os.html#interface-to-the-scheduler
   It might be worth to take a look and figure out whether we can include some
   of those in psutil.
   Also, we can probably reimplement wait_pid() on POSIX which is currently
   implemented as a busy-loop.

 * Certain systems (XXX figure out which ones exactly) provide CPU times about
   process children. On those systems Process.get_cpu_times() might return
   a (user, system, user_children, system_children) ntuple.