Has the same semantics as process-wait, but does not interact with the scheduler.
has same semantics as process-wait, but is "local", which here means that it does not interact with the scheduler. The scheduler does not call the wait function and hence never wakes the waiting process
The wait function is called only by the calling process, before going to sleep, and whenever it is "poked". A process is typically "poked" by calling process-poke, but all the other process managing functions (process-unstop, process-interrupt, process-kill) also "poke" the process. Returning from any of the generic Process Waiting functions (see Generic Process Wait functions) or
also implicitly pokes the process. A process may be also poked internally.
Because the wait function is checked only when the process is poked, it is the responsibility of the application to poke the process when it should check the wait function. This is the disadvantage of
Note: See process-wait-local-with-periodic-checks and process-wait-local-with-timeout-and-periodic-checks for functions that periodically check the wait functions.
One advantage of using the "local" waiters is that the wait function is called only by the waiting process. This means that the wait function does not have any of the restrictions that the wait function of process-wait has. In particular:
t(because this happens at most once).
cl:sleep, with a small caveat: since these functions may implictly "poke" the process, if the wait function calls any of them and then returns
nil, it may be immediately called again (if it returns
process-wait-localitself returns). Normally this is not a problem, because it is still waiting, but it does mean that the wait function is called more times than expected.