Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Paolo Amoroso <amoroso@mc...> - 2003-11-28 12:15:06
Does SB-THREAD provide a way of listing all threads? I mean something
like CMUCL's MP:ALL-PROCESSES. I'm just curious, I don't need this
feature right now.
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Quoting Paolo Amoroso (amoroso@...):
> Does SB-THREAD provide a way of listing all threads? I mean something
> like CMUCL's MP:ALL-PROCESSES. I'm just curious, I don't need this
> feature right now.
sb-aclrepl has this function:
(defun thread-pids ()
"Return a list of the pids for all threads"
(let ((offset (* 4 sb-vm::thread-pid-slot)))
#'(lambda (sap) (sb-sys:sap-ref-32 sap offset)))))
Perhaps it could be moved into package sb-thread as an exported symbol?
Quoting Daniel Barlow (dan@...):
> I'm not violently opposed to it. I wonder, though, what people want
> to do with the answers: by the time the list is consed, the data may
> no longer be valid. In thw worst case (which would probably involve
For example: Display a list of processes. (And so does sb-aclrepl.)
Users have to deal with that uncertainty every time they type "ps" or
> someone trying to break it deliberately, I concede) you could even get
> a thread id that now belongs to another non-sbcl process altogether.
I wouldn't dare asking for thread objects, which know whether they still
exist or not and have a name...