[Openmcl-devel] (ccl:all-proccesses) invariant
gb at clozure.com
Thu Jan 12 17:30:23 EST 2006
On Thu, 12 Jan 2006, David L. Rager wrote:
> Is it true that the function (ccl:all-proccesses) will always return
> with an ordering, where the oldest threads are last on the list? I am
> writing a function to kill all processes non-central to the OpenMCL
> system, and this invariant would be nice to know about if it exists.
MAKE-PROCESS pushes the newly created process onto the front of a list.
When a process exits or is reset, it removes itself from that list.
If a reset process is later preset, it'll push itself on the front
again. (So, it happens that things are more-or-less in most-recent-first
order, but that's just because PUSH is cheaper than APPEND or NCONC.)
ALL-PROCESSES returns a copy of that list (there's no way to obtain
the real, internal list; as soon as ALL-PROCESSES makes a copy, some
new/dying/recently-preset process might add itself to or remove itself
from the internal list, so there's always a small chance that ALL-PROCESSES
is a little out of synch.
Processes have a "serial number": an internal counter is incremented
every time a process is created, and that number's used to identify
the process. The initial process has a serial number of 0 and the
main listener thread almost always has the next highest serial number
(1 in a first-generation heap image, > 1 in something that's the
result of more than one SAVE-APPLICATION call.)
If you didn't want to trust the ordering (and don't mind consing a bit),
a) call ALL-PROCESSES; walk the list and note the smallest non-zero
serial number. That'll typically be the main listener thread,
and will be the oldest thread in the world (except for the initial
b) call ALL-PROCESSES again, killing anything newer than (with a
higher serial number than) the main listener.
More information about the Openmcl-devel