[Openmcl-devel] (process-suspend *current-process*) ?
Arthur W Cater
arthur.cater at ucd.ie
Thu Feb 5 05:47:25 PST 2009
Thanks Gary for the explanation.
As for using EVAL, right now I'm just mimicking what Digitool's MCL provided.
Looking at their source yesterday taught me something new - that one could pass
a function to be funcall-ed instead of a form to be eval-ed. Your advice will be followed!
----- Original Message -----
From: Gary Byers <gb at clozure.com>
Date: Thursday, February 5, 2009 1:31 pm
Subject: Re: [Openmcl-devel] (process-suspend *current-process*) ?
To: Arthur W Cater <arthur.cater at ucd.ie>
Cc: Openmcl-devel <Openmcl-devel at clozure.com>
> 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
> 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
> probablya 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
> implementationreasons 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
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openmcl-devel