osdir.com
mailing list archive F.A.Q. -since 2001!



Subject: Re: Process-resume hangs - msg#00003

List: lisp.openmcl.bugs

Mail Archive Navigation:
by Date: Prev Next Date Index by Thread: Prev Next Thread Index

(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 functions that you traced (CCL::%SUSPEND-TCR and CCL::%RESUME-TCR)
just call these C functions:

Boolean
lisp_suspend_tcr(TCR *tcr)
{
Boolean suspended;
TCR *current = get_tcr(true);

LOCK(lisp_global(TCR_LOCK),current);
suspended = suspend_tcr(tcr);
UNLOCK(lisp_global(TCR_LOCK),current);
return suspended;
}

Boolean
lisp_resume_tcr(TCR *tcr)
{
Boolean resumed;
TCR *current = get_tcr(true);

LOCK(lisp_global(TCR_LOCK),current);
resumed = resume_tcr(tcr);
UNLOCK(lisp_global(TCR_LOCK), current);
return resumed;
}

So if the current thread suspends itself, it won't UNLOCK the TCR_LOCK
and anything waiting on the TCR_LOCK will wait forever. (That
includes attempts to resume any suspended thread, or invoke the GC, or
a few other things.)

I'm tempted to say that the documentation should be changed and
that PROCESS-SUSPEND should detect attempts to suspend the current
process and refuse to do so. Using a semaphore - as in:

(defvar *a-semaphore* (make-semaphore))

(let* ((proc (process-run-function "example"
#'(lambda ()
(format t "~& suspending test process")
(wait-on-semaphore *a-semaphore*)
(format t "~& resumed ~%")))))
(sleep 5) ; or whatever
(signal-semaphore *a-semaphore*))

- is likely to be more robust for lots of reasons.





On Mon, 9 Jan 2006, Dan Corkill wrote:

> The following simple test hangs in the call to process-resume (running
> on "Version 1.0 (DarwinPPC32)"):
>
> (in-package :common-lisp-user)
>
> (defun simple-test ()
> (let ((process
> (ccl:process-run-function
> "Test"
> #'(lambda ()
> (format t "~&;; Suspending test process...~%")
> (finish-output)
> (ccl:process-suspend ccl:*current-process*)
> (format t "~&;; Resumed~%")
> (finish-output)))))
> (format t "~&;; Starting test...~%")
> ;; Allow plenty of time for test process to start up and suspend:
> (sleep 3)
> (format t "~&;; Resuming test process...~%")
> (finish-output)
> (ccl:process-resume process)
> (format t "~&;; Test completed.~%")))
>
> (progn (trace ccl::%suspend-tcr)
> (trace ccl::%resume-tcr))
>
> (simple-test)
>
>
>
>
>
> _______________________________________________
> Bug-openmcl mailing list
> Bug-openmcl@xxxxxxxxxxx
> http://clozure.com/mailman/listinfo/bug-openmcl
>
>


Thread at a glance:

Previous Message by Date:

Re: problem with pprint dispatch

The initial value of *PRINT-PRETTY* is implementation-dependent. It's false/NIL in OpenMCL; it may be non-NIL in other implementations (and apparently is in SBCL.) When *PRINT-PRETTY* is true, OpenMCL seems to use the pprint dispatch table as it should (at least in your example.) On Mon, 9 Jan 2006, [ISO-8859-1] Sebastián González wrote: I'm trying to define my own printer function for the 'vector type, by means of set-pprint-dispatch. In SBCL the following code works, but in OpenMCL it doesn't: (set-pprint-dispatch 'vector #'(lambda (stream object) (print-unreadable-object (object stream :type nil :identity nil) (format stream "OBJECT") (loop with *print-circle* = t with *print-level* = 1 for slot across (subseq object 1) do (format stream " ~a" slot))))) (format t "~a~%" (make-array 3 :initial-contents '(9 8 7))) => #<OBJECT 8 7> (in SBCL - calls my custom vector printer) => #(9 8 7) (in OpenMCL - calls the default vector printer) I use OpenMCL version 1.0 (beta: DarwinPPC64). _______________________________________________ Bug-openmcl mailing list Bug-openmcl@xxxxxxxxxxx http://clozure.com/mailman/listinfo/bug-openmcl _______________________________________________ Bug-openmcl mailing list Bug-openmcl@xxxxxxxxxxx http://clozure.com/mailman/listinfo/bug-openmcl

Next Message by Date:

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

Previous Message by Thread:

Process-resume hangs

The following simple test hangs in the call to process-resume (running on "Version 1.0 (DarwinPPC32)"): (in-package :common-lisp-user) (defun simple-test () (let ((process (ccl:process-run-function "Test" #'(lambda () (format t "~&;; Suspending test process...~%") (finish-output) (ccl:process-suspend ccl:*current-process*) (format t "~&;; Resumed~%") (finish-output))))) (format t "~&;; Starting test...~%") ;; Allow plenty of time for test process to start up and suspend: (sleep 3) (format t "~&;; Resuming test process...~%") (finish-output) (ccl:process-resume process) (format t "~&;; Test completed.~%"))) (progn (trace ccl::%suspend-tcr) (trace ccl::%resume-tcr)) (simple-test)

Next Message by Thread:

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
blog comments powered by Disqus

Home | News | Sitemap | FAQ | advertise | OSDir is an Inevitable website. GBiz is too!