|
osdir.com mailing list archive F.A.Q. -since 2001! |
|
|
|
Subject: Re: Process-resume hangs - msg#00003List: lisp.openmcl.bugs
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 dispatchThe 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 hangsGary, 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 hangsThe 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 hangsGary, 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
|
|