Ok,here is the problem of the day.
If you don't apply my latest push / fix, and go to this site, it locks you out in what seems like an infinite loop.
You can type and type and nothing happens.
Hit control c and get the usual "type qt to quit" message, but still you have no access.
You have to kill the process. At least that's what happens over here.

http://www.huffingtonpost.com/entry/the-inevitability-of-impeachment_us_588e8d52e4b0b065cbbcd09f

I thought my code was traversing a broken tree forever, again, or some such, but no.
I fixed those problems.
This site has a half doesn't timers, actually intervals, that fire every 50ms.
My implementation is sufficiently slow, or perhaps I have the wrong priorities on select() channels, or some such, that I am locked out.
As a bandaid, I now wait at least 230ms before running timers.
That is the latest push.
It's just a couple lines of code.
I actually don't think this is a bad idea.
Timers firing every 50ms almost surely exist to render fast visual effects, which are lost on us.
If it takes a couple minutes to read a message on the screen, or understand what part of the screen has changed,
then there's just no reason to change the screen 20 times a second.
Slowing down the process fixes the problem.
I can enter commands and edbrowse responds.
Type db4 and oh yes you can see the timers firing, and the screen rerendering, even though nothing on the screen changes.
Type db1 to go back to quiet.
It works, though even at this level it consumes 10% of my processor.
If I happen to have 10 such web pages open, either in parallel or pushed up onto the stack, the whole processor is churning.
So we don't have a clear solution yet.
Obviously the real browsers fire these timers 20 times a second without making a dent in cpu usage and without blocking user input.
No idea how they do it.

Anyways, the web page works now, and as for its contents, I can only hope he's right.

Karl Dahlke