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
• 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.

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

Copyright (c) 1998-2016, Franz Inc. Oakland, CA., USA. All rights reserved.
This page was not revised from the 8.1 page.
Created 2010.1.21.