[Edbrowse-dev] One program Two processes

[Karl Dahlke <eklhad@comcast.net>]

> Also, we're going to *have to* make js run asynchronously one of these days

Well I hope we don't, in the most literal sense of "asynchronous",
Because it's 10 times harder.
Here's what I mean.

Let http requests run in the background,
truly in the background, in parallel with everything else,
because these are the only tasks that might take more than a millisecond.
We already do this with our background downloads, and it is truly asynchronous.
When a request is complete, from xhr for example,
then a piece of js could run, serialized with other pieces of js
and with edbrowse itself.
Separate instances of js never run together, and how could they?
Think AutoCompartment in mozjs 24, which puts you in a specific context.
So js from two different windows can't really run in parallel, it all has to be serialized,
this chunk running in this window in this context in this compartment,
now that chunk in that compartment etc.
It has to be a timeshare system,
which is better for us anyways, easier to design,
ammenable to messages and pipes,
and *much* more threadsafe if we go with threads in a process.

Timers work this way now.
It looks like they're completely asynchronous, and they work just like
they're suppose to, but in reality it's timeshared
to keep the code simple and the interactions down to a minimum.
A snippet of js runs under a timer, or some js code runs on behalf
of edbrowse, or edbrowse itself is editing or formatting or posting
or whatever. All serialized.
The big test is
http://www.eklhad.net/async
run three of these in parallel and edit something in buffer 4.
Timers queue up with the work you are doing but it all serializes,
so when a timer fires in buffer 1, js runs in context 1,
including AutoCompartment on the js side, and then it finishes and something else happens,
and the buffers and js and doms don't get mixed up,
and they don't get confused with the work you are doing in buffer 4 in the foreground,
and this was a fair piece of work to get right
and it's not trivial, but now that it's timeshared
I'm pretty confident the windows and contexts won't collide.
Oh another test which I have done is to run async as above
but in the same buffer edit or browse something else on top of it,
which pushes async down on the stack.
But it's still there and its timer still runs
and when you use your back key to go back
it has the right time on the display.

This timeshare approach keeps things manageable, and I hope we are able to
continue with it.
It also makes the one process design at least feasible,
which we can continue to bat back and forth.

As for xhr I would probably create a mock timer that fires 5 times a second
and does nothing if the background http is stillin progress,
but if it's done then the hxr js snippet runs, under the timer,
and the timer deletes and goes away.
It keeps everything timeshared as above.
At first this design seems awkward and contrived,
but it might be a bit like democracy, the worst,
except for all the others.

If we do retain our two processes, or even more,
it would be easier if they were the same image, as they are now, and they just
do different things.
We tried to keep edbrowse-js lean and mean but found that it needed 30%, 50%, 60% of edbrowse,
so now it's all there,
with a global variable that reminds us we're really the js process.
cmake under windows really works better if each sourcefile is mentioned once,
as Geoff explained to me, so putting things together in libraries,
no problem for two processes but becomes combinatorially difficult for more,
so again one image is easy.
Only down side is you can't even build the basic edbrowse without the js library.
That is a downer,
but fortunately Chris maintains statics so people can run the program
even if they have trouble building it for any reason.
And we don't have to make our libraries shared or dll,
one image on disk and in memory, just running different ways.

> I think that maintaining two concurrent DOMs is only sustainable to a point.

I think we'll have to forever, in that we want edbrowse to browse even
if there is no js, yet when js does run it mucks with the tree
directly with native methods and that tree changes line by line,
moment by moment, before we can resync with edbrowse.
Anyways it's not easy no matter how you slice it.


Karl Dahlke