On Jun 24, 2009, at 1:16 PM, Helmut Eller wrote:
- Terje Norderhaug [2009-06-24 02:35+0200] writes:
Where do we go from here?
I'd say we should implement a backend function, say thread-attributes, for some Lisps. thread-attributes could just return a plist and the list-threads function can then figure out how to send them over the wire. By default list-threads should just return everything (including the attribute names in the first "row") and if we ever feel a need for filtering we can add that as optional argument.
I second that. Here is a candidate implementation that is flexible when it comes to the plist returned by thread-attributes. I have included a working tread-attributes function for openmcl.
; swank-backend.lisp
(definterface thread-attributes (thread) "Returns a plist of implementation-dependent attributes for the THREAD")
; swank.lisp
(defslimefun list-threads () "Return a list ((ID NAME STATUS DESCRIPTION ...) ...) of all threads, with the first item in the table being a list of attribute names and the rest containing the corresponding attribute values (possibly excluding trailing null values)." (setq *thread-list* (all-threads)) (loop with labels = NIL for thread in *thread-list* for name = (thread-name thread) for attributes = (thread-attributes thread) do (do ((plist attributes (cddr plist))) ((null plist)) (unless (find (car plist) labels) (setf labels (nconc labels (list (car plist)))))) collect (list* (thread-id thread) (if (symbolp name) (symbol-name name) name) (thread-status thread) (thread-description thread) (loop for label in labels collect (getf attributes label))) into result finally (return (cons (append '(id name status description) labels) result))))
; swank-openmcl.lisp
(defimplementation thread-attributes (thread) (list 'swank::priority (ccl::process-priority thread)))
-- Terje Norderhaug