process-wait

Arguments: whostate function &rest arguments

This function suspends the current process (the value of *current-process*) until applying the wait function function to arguments yields true. The whostate argument must be a string which temporarily replaces the process' whostate for the duration of the wait. This function returns nil.

If the wait function, function, is one of these:

• gate-open-p or (symbol-function 'gate-open-p)
• read-no-hang-p or (symbol-function 'read-no-hang-p)
• write-no-hang-p or (symbol-function 'write-no-hang-p)
• stream-listen or (symbol-function 'stream-listen)

then the wait can be scheduled without any additional effort. If a more general wait funtion is used, then in the native threads model Allegro CL starts a non-process support thread to make sure the general wait conditions are tested periodically. They will be tested in any event before the lisp goes idle, but the general-wait-tester, as it's called, ensures that the tests are made at reasonable intervals. See also *general-wait-delay*.

See Gates in multiprocessing.htm for a discussion of gates, one of the efficient choices.

Wait functions get called arbitrarily many times and they may be called in a dynamic state (and in a thread) other than that of the waiting thread that specified it. They are typically also called even after they have returned non-nil (that is, after they have already indicated the wait is over). Because of this, wait functions with side effects should be coded very carefully so that the multiple calls and calls after they have returned non-nil do not cause problems. And all wait funcions:

• should be fast
• must do no i/o
• in a non-SMP Lisp, should not reference dynamic-extent data, as such data may not be visible from a thread other than the one which allocated the data while the wait function may be called from any thread. (In SMP Lisps not only is all stack-allocated data visible to all threads, but wait functions are always run on the thread doing the wait, within the dynamic environment of the wait, so all stack-allocated data is still valid.)
• must not process windows messages
• must not wait on anything (directly or indirectly, so no calls to with-timeout or with-process-lock, for example)
• must not contain without-interrupts or without-scheduling forms

If a wait function signals an error, the waiting thread will no longer be waiting; it will call the wait function again, outside the scheduling regime, and react there to the signalled error.

See the discussion in the following sections in multiprocessing.htm for information on why not to use this function when waiting for input from a file.

• Waiting for input from a stream
• mp:process-wait vs mp:wait-for-input-available

See also wait-for-input-available and waiting-for-input-available.

See About design considerations for event-driven applications in cgide.htm and post-funcall-in-cg-process if you intend to call this function is a Common Graphics process.

Arbitrary wait functions in non-SMP Lisps

Handling arbitrary wait functions may require a heartbeat process must be running (one is already running in SMP Lisps). You can do this be evaluating:

(mp:process-run-function "heartbeat" #'(lambda () (loop (sleep 1))))

If no heartbeat is running, you may get a bus error with an arbitrary wait function.

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.