[squeak-dev] Re: losing mouse clicks
andreas.raab at gmx.de
Tue Dec 23 06:35:13 UTC 2008
Hi Göran -
The first thing to check is what priorities these various processes are
at. I would guess that if you keep hitting your listener loop hard
enough it would at some point consume all available CPU. And if any of
the processes keeps eating CPU at high priority your UI will become
unresponsive at some point (note that the effect can be hidden - for
example if you have a gazillion Delays they could conceivably block the
timer event handler adding/removing Delays from the lists etc).
A good thing to do is when the whole UI is unresponsive is to ask the VM
what it is currently doing by calling printCallStack or printAllStacks.
In our server VMs -USR1 is hooked up to do this but you can run the VM
under gdb (or attach gdb --pid when it's in this state) and ask gdb to
call printCallStacks(). Do this a couple of times to give the result a
bit more statistical validity and at the end you can be pretty sure
that's where it is spending time.
Göran Krampe wrote:
> ...and while on the "subject":
> When hacking on Blackfoot (my SimpleCGI implementation) I have noticed
> that banging on Blackfoot through Nginx (a web server) using ab (apache
> benchmark) the image seem to inevitably (but definitely not immediately)
> end up in a state where it does not take mouse/keyboard events nor
> redraws when being resized. However - it still cranks out SCGI responses
> like before. So it doesn't seem to happen easily, but when pushing it
> with thousands of requests it eventually happens.
> So somehow the UI died but Socket and the listening Process etc works
> just fine.
> I presume this can happen using KomHttpServer or whatever, intuitively
> it can't be something Blackfoot does - anyone seen it?
> Using... oh darn, the VM is way old :) It is a 3.9-8, and a 3.9 7067
> image. I will see if it still appears with the newest VM/image combo.
> regards, Göran
More information about the Squeak-dev