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.

Cheers,
   - Andreas

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