[Openmcl-devel] My beach balls runneth over

[Gary Byers]

Is this a fair characterization of what we know so far:

- when using third-party code under the IDE, the system becomes periodically
   unresponsive in ways that may have something to do with the fact that that
   code generates (possibly large amounts of) diagnostic output and with
   AltConsole's ability to keep up with it ?

   FWIW, I tried modifying the #/sendEvent: method (in cocoa-ide/cocoa-utils.lisp)
   so that it did:

   (apropos "NX" "CCL")

   at the beginning of its body.  On a ~3GHz iMac, that was enough extra work
   for the event thread that scroll-bar tracking was unreliable but the system
   rarely beachballed;  if I changed that to:

   (apropos "" "CCL")

   I couldn't get a word in edgewise: the event thread was so busy either generating
   output or blocking waiting for previously buffered output to be read that it
   was unable to process events.

   Both cases probably involve more output being generated than what you're seeing,
   but the different behavior and the fact that some other people have difficulty
   reproducing what you see suggests that what happens here may have to do with
   processor speed and system load;  I can think of some ways to speed this up,
   but it's generally not a good idea to do potentially blocking I/O operations
   in event handlers.  Doing

   (loop)

   in an event handler is a very bad idea.

- when using the same third-party code under the IDE, you crashed into the
   kernel debugger, apparently in some code having to do with anticipatory
   symbol completion ?

   I remember thinking that the code described in:

   <http://clozure.com/pipermail/openmcl-devel/2009-January/008803.html>

   was trying to do drawing from a secondary thread without taking
   appropriate precautions before doing so.  (See the examples in
   <http://trac.clozure.com/openmcl/wiki/CocoaBridge> for more information
   about this.)

   If I'm correct in thinking that that was a problem that caused
   the anticipatory symbol completion code to sometimes work and sometimes
   crash, I'm not sure that anyone ever followed up on it; if I'm
   misremembering ... never mind.

It's certainly possible that general IDE instability is responsible for
or contributes to these problems, but it also seems possible that neither
of these things is anything that we have any direct control over, and
it seems premature to conclude anything about general IDE [in]stability
based on these examples.

Does anyone disagree with this ?




On Tue, 19 May 2009, Ron Garret wrote:

>
> On May 19, 2009, at 2:16 PM, Raffael Cavallaro wrote:
>
>
>> I don't see any of this. I'm running trunk though. Maybe you should switch?
>> 
>
> Trying that now.  For the record, the version I was running came from the 
> instructions on http://trac.clozure.com/openmcl:
>
> The preferred way to get Clozure CL is via Subversion. For example, to get 
> Clozure CL 1.3 for Darwin/x86, you'd type (where the $ is the shell prompt):
>
> $ svn co http://svn.clozure.com/publicsvn/openmcl/release/1.3/darwinx86/ccl
>
> If people should be running the trunk this probably ought to be changed or 
> I'm not going to be the only one having these problems.
>
> Also for the record, I can tolerate a certain amount of instability at the 
> moment if problems like this are being fixed relatively quickly (like hours 
> to days rather than weeks to months).  I'm not doing anything 
> mission-critical right now, so it's actually a good time for me to be a 
> guinea pig.
>
> rg
>