Allow for "continuous update" of started/ended processes

[BenBE]

With #241 watching for processes that recently started/ended becomes quite easy to follow. Unfortunately the default delay for process updates is quite large thus when e.g. running make or other tools that create lots of short-lived children you are going to miss most of the action.

With most systems there exists a facility in form of dtrace that should allow to actually monitor the process creation/termination in "real-time" thus no longer missing any child born - no matter how short-lived.

Some constraints:

• Requires root (an alternative using inotify on /proc doesn't seem to work - no IN_CREATE/IN_DELETE on /proc// directories received 😢 )
• Should only collect quick initial data outside regular update cycle
• Implementation using dtrace may be quite platform dependent despite providing a similar interface on most platforms
• Will likely require some major changes to the internal handling of the process list (cf. e.g. Improving Command display/sort #42, Add support for sorting in Tree mode #240)
• Might be quite heavy on the system load on busy systems 😢

This really is an enhancement idea, but I don't see a chance for any near-term implementation, thus low-prio / wishlist. Patches implementing this welcome anyway.

[fasterit]

As discussed on irc with @BenBE ... possible with eBPF:
https://github.com/iovisor/bcc/blob/master/tools/execsnoop.py
https://bolinfest.github.io/opensnoop-native/

[cgzones]

Maybe related: https://natanyellin.com/posts/tracking-running-processes-on-linux/

[cgzones]

Another idea might be to not have a big delay (default: 1.5s) and gather all data on each cycle, but having a small (0.2s?) delay and check only newly detected processes until the next full-data-cycle.

[BenBE]

This might work sufficiently well for small numbers of processes changing between each cycle. You could even improve on this by using a FIFO queue of processes waiting for updates. That way you could even limit the number of updates in such a "partial" cycle to a certain maximum. Combined with the TreeSet information from the tree building in #307 you could probably also speed-up the insertion/removal of new processes without rebuilding the whole tree.