<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>have not done much testing but for the simple cases seems to work. Thanks Gary!</div><div><br></div><div>Would people mind/object/protest/welcome if RMCL would be checked into Google Code? It would make updating and tracking RMCL (via svn) quite a bit simpler. I doubt there will be many changes but even just a handful of updates would be tricky to track as diff fragments distributed in various emails.</div><div><br></div><div>Alex</div><div><br></div><br><div><div>On Aug 1, 2009, at 1:09 PM, Gary Byers wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>I'm fairly sure that adding a couple of lines near the end of the LAP<br>function %SAVE-STACK-GROUP-CONTEXT (in "ccl:level-1;PPC;ppc-stack-groups.lisp")<br>will fix the problem that causes PROCESS-RUN-FUNCTION to sometimes crash,<br>as suggested by the following diff:<br><br>Index: level-1/PPC/ppc-stack-groups.lisp<br>===================================================================<br>--- level-1/PPC/ppc-stack-groups.lisp<span class="Apple-tab-span" style="white-space:pre"> </span>(revision 223)<br>+++ level-1/PPC/ppc-stack-groups.lisp<span class="Apple-tab-span" style="white-space:pre"> </span>(working copy)<br>@@ -1685,6 +1685,8 @@<br> (svset data sg.ts-overflow-limit sg t)<br> ; Prevent stack overflow when we reenter this code (may not be necessary)<br> (set-global rzero cs-overflow-limit)<br>+ (set-global rzero vs-overflow-limit)<br>+ (set-global rzero ts-overflow-limit)<br> (set-global rzero db-link))<br> (blr))<br><br>The problem (at least the problem that I'm aware of) has to do with how<br>stack-overflow is detected in RMCL. An (R)MCL thread has 3 stacks, where<br>the thread's "control stack" is the hardware stack (addressed by r1 on the<br>PPC) and the "value" and "temp" stacks are used for (roughly) fixed- and<br>variable-sized lisp objects. In native MCL, overflow on the temp and<br>values stacks could be detected by write-protecting some guard pages<br>at the end of the stack and handling the resulting exception. Since <br>exceptions don't work under Rosetta, in RMCL it's necessary to check<br>for overflow in software (by comparing the appropriate stack pointer<br>to a global variable and signaling a stack-overflow if the stack pointer<br>is "unsigned less than" the limit.<br><br>Only one thread can run at a time in (R)MCL, and part of context-switching<br>between threads (stack-groups, actually ...) involves copying some global<br>state into the outgoing thread, making the global state "thread neutral",<br>and then copying the incoming thread's state to the global variables. (These<br>global variables include the current thread's stack overflow limits.)<br><br>One of the first things that a new thread does is to try to determine what<br>its stack overflow limits should be. Until it's done this (and set the<br>appropriate global variables), any software stack-overflow checks that the<br>new thread does have to use the "thread-neutral" value 0 (no stack pointer<br>can be "unsigned less-than" 0.) Because the outgoing thread neglected<br>to zero out the global temp- and value-stack limits (in the +-prefixed lines<br>in the patch above), the first few stack-overflow checks in a new thread<br>compared the stack pointer to the previously active thread's limit. This<br>is completely wrong, but it has a 50% chance of being accidentally right<br>(depending on the relative addresses of the outgoing thread's stack and<br>the incoming thread's.) Roughly half the time, the new thread would<br>get a spurious stack overflow before it'd even finished initializing<br>itself and this generally led to an immediate crash.<br><br>AFAICT, this doesn't have anything to do with event-processing per se,<br>but it may be the case that switching to a new thread from the event<br>thread would fail and switching to the new thread from (e.g.) the <br>listener thread would succeed, and this has to do with the more-or-less<br>arbitrary relative addresses of the incoming and outgoing threads' stacks.<br><br>I haven't seen PROCESS-RUN-FUNCTION fail since making the 2-line change<br>above. That's not conclusive (since I hadn't seen it fail until Andrew<br>told me about the discussion on this list a few weeks ago), but the explanation<br>above seems to be consistent with the (somewhat unpredictable) behavior<br>that people here have reported, and the 2-line fix above seems to fix the<br>problem.<br><br><br>On Sat, 1 Aug 2009, Terje Norderhaug wrote:<br><br><blockquote type="cite">On Jul 20, 2009, at 4:22 PM, Alexander Repenning wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">Just wondering... has anybody found any work around the process problems in <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">RMCL. At least so far I have not been able to use process-run-function in a <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">way that is NOT causing a crash.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The enclosed patch attempts to work around the process problems in RMCL, as a <br></blockquote><blockquote type="cite">potential remedy until we have a proper fix. It exploits the observation that <br></blockquote><blockquote type="cite">processes can be started in the event handler without crashes. The patch <br></blockquote><blockquote type="cite">advises process-run-function and should not require changes to any other <br></blockquote><blockquote type="cite">code.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">-- Terje Norderhaug<br></blockquote><blockquote type="cite"><br></blockquote>_______________________________________________<br>info-mcl mailing list<br><a href="mailto:info-mcl@clozure.com">info-mcl@clozure.com</a><br>http://clozure.com/mailman/listinfo/info-mcl<br></div></blockquote></div><br><div apple-content-edited="true"> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font: 12.0px Helvetica">Prof. Alexander Repenning</font></p><p style="margin: 0.0px 0.0px 0.0px 0.0px"><br class="khtml-block-placeholder"></p><p style="margin: 0.0px 0.0px 0.0px 0.0px">University of Colorado</p><p style="margin: 0.0px 0.0px 0.0px 0.0px">Computer Science Department</p><p style="margin: 0.0px 0.0px 0.0px 0.0px">Boulder, CO 80309-430</p><p style="margin: 0.0px 0.0px 0.0px 0.0px"><br class="khtml-block-placeholder"></p><p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font: 12.0px Helvetica">vCard: <a href="http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf">http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf</a></font></p><br class="Apple-interchange-newline"></span></span></span></div></span> </div><br></body></html>