[Openmcl-devel] (process-suspend *current-process*) ?

[Gary Byers]

The documentation's wrong; the function's right in claiming that it can't
possibly work.

(At one point it may have worked: a process could suspend itself and hope
that something would later resume it.  It then became clear that - to the
extent that PROCESS-SUSPEND is even a good idea - that PROCESS-SUSPEND
and PROCESS-RESUME needed to own a lock.  (PROCESS-SUSPEND *CURRENT-PROCESS*)
would disable the current process while owning that lock; any other thread
that tried to resume it would wait for that lock.)

There are all kinds of other ways to deadlock via PROCESS-SUSPEND; if the
documentation doesn't scare you out of trying to use it (unless you're
very, very careful), it should.

Once in a blue moon, suspending a thread is the right way (or the only
way) to do things.  That's also true of calling EVAL, but it's generally
good advice that if you find yourself calling EVAL, you should pause
and ask yourself if you're doing things the right way.  (In the case of
EVAL, well ... sure, sometimes it's the only way to do something.  If
it isn't the only way, other ways are almost better.)

Sometimes - mostly for debugging - it's necessary to find the value of
the binding of a special variable in another process
(e.g. SYMBOL-VALUE-IN-PROCESS).  It's very difficult to look at another
thread's stack while that thread is running (and its stack pointer and
stack contents are changing.)  Suspending the other thread (or otherwise
trying to ensure that it's in some static, quiescent state) is probably
a necessary part of the implementation of SYMBOL-VALUE-IN-PROCESS and
things like that; in SYMBOL-VALUE-IN-PROCESS, two threads (the caller
and the target process) are contending for a resource (the target
process's stack), and there isn't a particularly good way to get the
target thread to stop using that resource (its stack) without putting
it to sleep.)  Most other resource-contention problems have less
drastic (and less risky) solutions.

PROCESS-SUSPEND is generally the wrong thing, and there are implementation
reasons that make suspending the current process impossible.  If those
reasons didn't exist, why would you want a process to suspend itself ?
The only way that it could wake up is if some other thread resumed it,
presumably in response to some external event.  Associating a semaphore
with that event is often a straightforward way of waiting for the event
to occur.



On Thu, 5 Feb 2009, Arthur W Cater wrote:

> Hi,
>
> I'm running Clozure Common Lisp Version 1.2-r11687M  (DarwinPPC32) Mac OS 10.5.6.
> I've just done svn update, (rebuild-ccl :force t), (require :cocoa-application).
>
> I'm trying to implement something similar to MCL's Eval-Enqueue, using a new process with a
> queue of forms, which when the queue gets empty does (process-suspend *current-process*)
> The following pops up in the console window:
>
>> Error: Suspending the current process can't work.  
>>         (If the documentation claims otherwise, it's incorrect.)
>> While executing: PROCESS-SUSPEND, in process Eval-Queue(6).
>
> The documentation does claim otherwise:
> "A process can suspend itself; it it's successful in doing so, then it can obviously only be resumed by some other process."
>
> I cannot find any tickets which mention process-suspend.
>
> (I guess I should use a wait-on-semaphore instead of process-suspend, process-resume.)
>
> Arthur
>
>
>