Show CPU usage and time since thread started to sly-threads view

[bo-tato]

I was debugging a multi-threaded program where some threads would hang at 100% cpu so I added some extra info to the thread view to spot it easier. It is only for sbcl and linux. Supporting other compilers and OS I think is possible if there is interest and someone available to test. I first added to the sbcl backend thread-attributes a :tid attribute with the OS tid/pid for each thread. Then on the elisp side if the :tid attribute is present, it will also add the elapsed time since the thread started, and the percent cpu usage since the last update of the threads buffer. The elapsed time it gets from emacs process-attributes function which is cross platform, however the cpu time returned by emacs 'process-attributes' for a given tid is for the process not the thread. As on linux emacs is reading /proc/tid/stat which does have the correct elapsed time per thread but has the cpu usage for the whole process, so I added a function to get the info from /proc/sly-pid/task/tid/stat

Here's a screenshot of it in action:

I'm thinking maybe I should remove the TID column cause the user probably doesn't care to see it, and make the time show in a nice format, I could just call proced-format-time but then sly would have to require proced.

Is just an idea and demo of it, I doubt it's of quality to merge into sly as is, I'm new at emacs and lisp so any feedback is welcome.

[Ambrevar]

Note that with-file-contents! does not exist (in Emacs 28).

[bo-tato]

oops it seems that is a convenience macro added by doom emacs, that can be replaced with:
(with-temp-buffer (insert-file-contents ...))
I also used when-let and I think some other functions added in emacs 25 or 26 while I think sly is intended to work on emacs 24? If it's wanted to merge this feature I can rewrite and test it against old emacs

[bo-tato]

I realize I designed this wrong. I thought I should put the minimal code possible in the slynk backend (just adding TID to the reported thread attributes), and lookup the thread information from TID on the elisp side so that it'd take as little code as possible to add other CL implementations. But this is mostly useful for debugging long running network services that is usually not running locally. Later I'll change it so the slynk backend reports the full thread information rather elisp looking it up locally, so that it works when connected to remote slynk instances.