D29615: Nice all threads of multithreaded programs

[David Edmundson]

davidedmundson accepted this revision.
davidedmundson added a comment.
This revision is now accepted and ready to land.


  > Still, I think this behavior is actually the only one usable,
  
  Indeed.  A user shouldn't be expected to know what each thread is doing inside an app, there isn't enough metadata to do anything useful there anyway. Especially with use of threadpools.
  
  FWIW,  I've been taking this logic further in the other direction from looking at threads. From 5.19 spawned apps will each have their own cgroup. The intention being to get to a point (5.20 or so) where we can do management on an entire cgroup (and therefore app with multi processes and threads) all at once. The management is way nicer, the UX is nicer, and we won't have this sort of problem.
  
  ------
  
  > Note: this only changes the behavir for remote computers. Local use needs a similar fix in libksysguard.
  
  Yeah, that's the more useful one.

INLINE COMMENTS

> ProcessList.c:657
> +    goto failure;
> +  /* NOTE: this is racy; threads may die or be spawned during our
> +     iteration. Inthat case, we either fail with an error or fail to

heh, our use of PID is already racey

REPOSITORY
  R106 KSysguard

BRANCH
  Plasma/5.18

REVISION DETAIL
  https://phabricator.kde.org/D29615

To: jpalecek, ahiemstra, davidedmundson
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20200512/39b8a082/attachment.htm>