On Sunday, October 26, 2014 2:50:15 AM UTC-4, puzzler wrote: > > On Sat, Oct 25, 2014 at 11:19 PM, Fluid Dynamics <a209...@trbvm.com > <javascript:>> wrote: > >> This is a really weird one, when you think about it. How the heck does a >> programmer make a mistake that results in the *file save* function going >> into an *infinite loop*? At least it didn't go into an infinite loop >> filling my filesystem... >> > > You're making a pretty big assumption that the bug happened in the file > save function. By your own admission, the file was saved perfectly fine, > so perhaps after the file was saved it triggered a screen refresh or a > project reload or a rescanning of the files in your directory, or any > number of things that could have hung due to something specific on your > system like a lack of sufficient memory or some file locked by another > process, or whatever. >
Most of those are I/O tasks which, if indefinitely impeded, would take the form of a 0% CPU use hang. What was actually observed, however, was the saturation of a core, which requires an actual infinite busy loop of some kind. (I terminated the process after about three minutes, by which time it was clearly not going to recover on its own. On the hardware at issue here, that represents well over half a trillion CPU instruction cycles. If a normally fast task has spun its wheels that much without making detectable progress, it's generally safe to assume it's permanently stuck. (Unlike something you expect to take such numbers of cycles and still eventually complete, such as intensive numerical or simulation work. By contrast, I can think of no task CCW should be expending hundreds of billions of cycles on. As with most document-editing tools it should be I/O bound, waiting on fresh user input the vast majority of the time and blocked waiting for platters to reach the right theta most of the *rest* of the time. The observed CPU saturated behavior is thus remarkably abnormal in context. I'll also note that the affected process was CCW itself, not the REPL server or any other component.) Oh, and an addendum: although my files were thankfully intact when I restarted CCW, it did come up in a wonky state the fix for which was less than 100% obvious. All attempts to start a project REPL were just spitting out a red message "Invalid REPL" into a REPL tab, instead of starting a REPL and presenting it there. Fixing this required *closing the REPL tab entirely* and *then* acting to start a new REPL. This does not happen after a graceful close and restart. The command to start a new REPL should "just work". If there was some uncleaned-up cruft left over from the abnormal termination of the previous session, relating to the REPL, which closing the REPL tab cleaned up, then the command to start a new REPL should perform any such clean-up on an as-needed basis rather than just complain "Invalid REPL", although tasks that assume an *existing* REPL might reasonably do so. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
