19.11 Other processes functions

19.11.1 Process Priorities

Each process has a priority and can either be runnable, blocked or suspended.

The effect of process priorities is significantly different between SMP LispWorks and non-SMP LispWorks.

19.11.1.1 Process priorities in SMP LispWorks

Process priorities are almost completely ignored in SMP LispWorks.

The main exception is that for processes that wait with process-wait for something to happen, a process with higher priority is likely to wake up earlier, but even then it is not guaranteed.

19.11.1.2 Process priorities in non-SMP LispWorks

If there is a runnable process with priority P, then no processes with priority less than P will run. When there are runnable processes with equal priority, they will be scheduled in a round-robin manner.

If a process with priority P is running and a blocked process with priority greater than P becomes runnable, the second process will run when the scheduler is next invoked (either explicitly or at the next preemption tick).

To find the priority of a process, use process-priority. This can be changed using change-process-priority.

(mp:change-process-priority proc-1 10)

Another way to specify the priority is to create the process with process-run-function, passing the keyword :priority:

(list
 (mp:process-run-function 
  "SORTER-DOT" '(:priority 10) #'sorter #\.)
 (mp:process-run-function 
  "SORTER-DASH" () #'sorter #\-))

19.11.2 Accessing symbol values across processes

Use symeval-in-process to read the value of a dynamically bound symbol in a given process.

(setf mp:symeval-in-process) can set the value of such a symbol.

symeval-in-process is mostly intended for debugging. Do not call it while the thread is actually running.

19.11.3 Stopping and unstopping processes

This section describes a typical way of using process-stop and process-unstop.

Suppose a pool of "worker" processes is managed by a "manager" process. A process in the worker pool marks itself as available for work, and then calls process-stop. The manager process later finds a worker process that is marked as available for work, puts the work in a place known to the worker process, and then calls process-unstop on the worker process.

For this scheme to work properly, the check of whether the worker is available needs to include a call to process-stopped-p. Otherwise, it is possible for the following sequence of events to occur:

1. A worker marks itself as available.
2. The manager process finds the worker and gives it the work.
3. The manager process calls process-unstop on the worker.
4. The worker process proceeds and calls process-stop, and never wakes up.

To guard against this possibility, then the manager should call process-stopped-p when finding the worker in the second step above. Alternatively, it could check the result of process-unstop.