> They're kind of authogonal and kind of not. With the separate process we can > keep spinning round the main input loop even if js is stuck in some expensive > operation.
In theory we could, but today we don't. I send a message over pipe to js process and block read waiting for a response. Things to consider though: 1. websites aren't going to write js code that computes a million digits of pi, at least not on purpose. I don't believe there are that many js expensive operations out in the wild. That's why I didn't mind waiting for the response. Second, I'm calling up the web page and I want to read the page, that is next on my list of things to do, I really don't want to go off to another buffer and do something else. If it's really that slow I'm going to be annoyed, whether I have the freedom to switch buffers while I wait or not. It just shouldn't be that slow. A measure of the quality of a mainstream browser is often how quickly it can bring up complex sweb pages. 3, so far the times it has been really slow is our fault, our DOM was not correct or complete and that caused js to go into a long loop, sometimes an infinite loop, and that wouldn't happen on another browser or on edbrowse if we had all our objects correct. I do understand what you're saying though and we need to keep it in mind. If the day comes when we say, "wow we just can't give up all control to js and wait for it to finish", then yes there are advantages to having it across the street. At this moment I don't thinkg waiting for a js routine to return is a show stopper, thus the simple design we have now. We'll see. Obviously I'm not doing anything yet that would throw away the 2 process design. Speaking of serialized poling and timers, one thing I had to do was scale back the intervals, so they can't fire 20 times a second, as they do on some sites for visual effects. Timers were always running and edbrowse would never listen to what I was typing at the keyboard. A blind person can't keep up with that kind of rapid fire screen refresh anyways. So I don't let intervals run more than a couple times per second and that solves the problem, but it illustrates some of the things we have to think about when coordinating all these "asynchronous" events. See html.c line 2210. I tell you, if you're running debug 4 or higher, even an interval that ticks every 2 or 3 seconds is annoying, spewing out periodic and regular debug messages, and getting in the way of what you're really looking for, but not much we can do about that. Karl Dahlke
_______________________________________________ Edbrowse-dev mailing list Edbrowse-dev@lists.the-brannons.com http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
