Note that any of those operations you're talking about under the general heading of "I/O tasks" are very complex in a modern IDE, and there are a lot of seemingly unrelated code paths where a bug or some sort of unexpected condition might cause an infinite loop. And as a lot of people have noted, the fact that it's the CCW process doesn't rule out the fact that it could be anywhere in the Eclipse infrastructure. If you'd like a recent concrete example of this, check out Cursive issue #517 <https://github.com/cursiveclojure/cursive/issues/517>, which turned out not to be a problem with Cursive at all, but a bug in the IntelliJ formatting engine totally unrelated to the apparent issue.
And as others have also noted, the best way to deal with this would be a polite issue in the CCW tracker. CCW obviously provides a lot of benefit to you and many others, I'm sure Laurent is a busy guy and CCW is more or less a labour of love for him - it doesn't seem like too much to ask. Cheers, Colin On 27 October 2014 07:26, Fluid Dynamics <a2093...@trbvm.com> wrote: > 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> >> 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. > -- 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.
