> Ok, so how're we going to do all the async js stuff we'll have to start doing
> properly soon? Tbh I'm not sure how much I'm attached to the multiple process
> idea other than it means js can go pop and we don't...

Right. They are orthogonal issues.
We're not going to spin off a separate process for every asynchronous thing that the browser might do,
it will either be threads or some sort of time share polling,
so the separate process was necessary due to the fragility of js,
but I think we're fixing that step by step, and when the js side is as solid as the edbrowse side I'd like to fold them back together into one process,
which the JS1 variable is a start.
I may add some more code over the next week, still under JS1, to simplify the code when it is one process.
So many times we can just call a function instead of passing messages around, and we wouldn't even need all those updates when curl data changes etc,
so something to work towards.

As for the larger question, I don't think I know enough yet to answer.
Honestly it makes me nervous to think of making all of edbrowse + duktape threadsafe.
Javascrip timers are implemented now, and well tested, e.g. http://www.eklhad.net/async
They don't spin on cpu cycles, they actually use timers, but they also signal the main input loop so that everything is serialized.
We process what you typed in, or we run the js code associated with a timer, and we're back.
There aren't any threads, and it works pretty well.
I'm not saying that will work for everything we need to do, I just don't know enough yet,
but if it would work for other situations it would be easier.

Cheers,

Karl Dahlke