[Openmcl-devel] My beach balls runneth over
gb at clozure.com
Tue May 19 20:03:02 EDT 2009
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
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:
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
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.
More information about the Openmcl-devel