Function | Package: mp | ToC | DocOverview | CGDoc | RelNotes | FAQ | Index | PermutedIndex
| Allegro CL version 10.1 Unrevised from 10.0 to 10.1. 10.0 version

## process-quantum

Arguments: process

This function and its associated value are ignored in SMP images.

Returns the quantum of process, which must be an instance of `mp:process`. The value is the number of seconds this process can hold the lisp heap before it will allow other ready processes a chance to run. Each time this process runs, the system should grant it at least this amount of time before preempting execution for another process. Currently defaults to 2, and may be set to any number greater than or equal to 0.1 and less than or equal to 20 with setf. The units are seconds.

In both process implementations, when a process starts running a timer interrupt is scheduled to go off after the quantum (real-time) expires. The process might block for some reason before the timer interrupt comes in, and in that case the interrupt is canceled. There are also reasons why the timer interrupt might be ignored for some time after it comes in: fast code (that does not check for interrupts, see `generate-interrupt-checks-switch`), atomic code (that explicitly ignores interrupts -- see without-interrupts, e.g.), and garbage collection are three examples. But once the timer interrupt is noticed, the process will quit running so other processes can get a chance.

On :os-threads implementations, all other processes will get a chance to run. On non :os-threads implementations, all processes with equal or higher priority get a chance to run.

In :os-threads implementations, a foreign call that releases the heap allows other processes to grab the heap. The process that made the call is still facing the interrupt-after-quantum, even though it may block on heap access when it returns from the foreign call.

If Lisp as a whole isn't getting many cycles, the cpu time corresponding to the real-time quantum may be pretty small, leading to virtual process thrashing.

Thus, there isn't too much we can say for sure about how much time the process will get to run before being preempted, except that for well behaved Lisp processes, it will normally be approximately equal to the process quantum.

See multiprocessing.htm for general information on multiprocessing in Allegro CL.

Copyright (c) 1998-2022, Franz Inc. Lafayette, CA., USA. All rights reserved.
This page was not revised from the 10.0 page.
Created 2019.8.20.

|  | ToC | DocOverview | CGDoc | RelNotes | FAQ | Index | PermutedIndex
| Allegro CL version 10.1 Unrevised from 10.0 to 10.1. 10.0 version