[Openmcl-devel] My beach balls runneth over

[Ron Garret]

I think it's actually much simpler than this.  I'm able to reproduce  
part of the problem simply by doing:

(dotimes (i 1000000) (print i ccl::*stdout*) (print i))

and then closing the AltConsole window.  It's not beach-balled in this  
case, but CPU usage is zero, and attempting to open a new listener  
hangs with a "Lock wait for recursive lock" message in the mini- 
buffer.  Re-opening the AltConsole makes it start up again.  Hm, turns  
out I can actually interrupt execution while it's hung in this case  
and verify that the counter is not incrementing.  The break is  
invariably in CCL::FD-WRITE, which is not surprising.

So what seems to be happening is that when the AltConsole window is  
closed, the AltConsole buffer backs up to the point where attempts to  
write to the AltConsole will block.  If while in this state the event- 
handling thread attempts to write to the AltConsole, it will block and  
you're wedged.

This does not explain why I sometimes end up in the kernel debugger,  
but it's possible we're dealing with two separate problems here.

rg


On May 19, 2009, at 5:03 PM, Gary Byers wrote:

> 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
>>