From: Paolo A. <am...@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. Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film |
From: David L. <da...@li...> - 2003-11-28 12:50:17
|
Quoting Paolo Amoroso (am...@mc...): > 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))) (sb-thread::mapcar-threads #'(lambda (sap) (sb-sys:sap-ref-32 sap offset))))) Perhaps it could be moved into package sb-thread as an exported symbol? |
From: Daniel B. <da...@te...> - 2003-11-28 13:37:46
|
David Lichteblau <da...@li...> writes: > Quoting Paolo Amoroso (am...@mc...): >> 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 () [...] 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 someone trying to break it deliberately, I concede) you could even get a thread id that now belongs to another non-sbcl process altogether. So, I'd be interested to know what it would be used for. Incidentally, I'm trying to eliminate the use of 'pid' in connection with threads. Althoigh thread ids and process ids happen to be the same thing on Linux, it's not necessarily the case that the same applies on other systems we might port to. -dan -- http://web.metacircles.com/ - SBCL custom developement and support |
From: David L. <da...@li...> - 2003-11-28 13:55:39
|
Quoting Daniel Barlow (da...@te...): > 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 "top". > 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... |
From: Daniel B. <da...@te...> - 2003-11-28 14:13:41
|
David Lichteblau <da...@li...> writes: > Quoting Daniel Barlow (da...@te...): >> 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 > "top". Fair enough. Happy to add it then, provided that people understand that they will certainly get a slapping (if not now, then some day) if they write code that does (terminate-thread (all-thread-ids)). That kind of Unix code we can do without. > I wouldn't dare asking for thread objects, which know whether they still > exist or not and have a name... The problem with this, at least historically, has been that if a thread is, say, kill -9'ed, it doesn't have much chance to update the associated thread object to say that it's dead: you need the parent to do that for it. But the parent for all the threads is a process that doesn't run Lisp, so making it update data in Lisp structures is hard work and leads to OAOOM. The reason that all threads share a parent is so that it can ptrace() to stop them for GC. However, we don't do this any more, so what I'm doing now <URL:http://ww.telent.net/diary/2003/11/#28.17227> is changing all that around so that Lisp threads get child exit messages and can take care of updating whatever thread-related structures are necessary. This will make moderately reliable thread objects at least /possible/. I'm still not sure they're absolutely necessary, but if every portable system is going to expect them and invent its own layer to cope (so mcclim won't show process pseudo-objects created by paserve and vice versa) that would be even more silly. In summary: be careful what you dare not ask for, you might just get it. -dan -- http://web.metacircles.com/ - SBCL custom software development and support |