Re: Process-resume hangs

Gary,

Thanks for the prompt response and clear explanation.

> (ccl:process-suspend ccl:*current-process*) can't work as implemented,
> and I'm not sure if -should- work.  (If it's decided that it shouldn't,
> it should probably detect that case and signal an error rather than
> fouling things up as it currently does.)
> 
> The documentation claims that a process can suspend itself and be
> resumed by another process; it also notes that PROCESS-SUSPEND can
> be dangerous, since the suspended process may own a lock or other
> resources, and this can (fairly easily) lead to deadlock.  It doesn't
> note the fact that that act of suspending a process requires a lock,
> and if a process suspends itself it continues to own this lock (that
> was either not true when the documentation was first written, or
> was simply overlooked.)

The background for the bug report is from testing for the CL Gardeners 
Portable-Threads initiative (http://wiki.alu.org/Portable_Threads). I've 
added a check and error-signal for self-suspension at the 
portable-threads interface layer.

I've always been nervous about the heavy-handed nature of 
suspend-process, and I am now soliciting opinions about removing 
hibernate/awaken-process from the portable-threads interface.  I assume 
that the cost of a long-duration wait for a semaphore in OpenMCL is not 
excessive in comparison to a suspended process.

Thanks for clarifying the documentation claim that self-suspension is 
supported in OpenMCL.

-- Dan