[Edbrowse-dev] IPC

[Karl Dahlke <eklhad@comcast.net>]

While Adam's arguments for a multi-process approach are compeling,
I still wonder if that should wait for a future date.
I guess there are two approaches: a complete rewrite that changes everything,
and leapfrogs all the way to the end,
or incremental changes to get us there.
If we can move step by step, I think the ipc separation would be
one of the last steps to take.
Given our limited resources,
just three volunteers working in spare time,
I kinda think we should go incremental,
though I realize there may be some jumps that just can't be done that way.

I'm trying to think of a piece or two that I could work on,
that would be a step in the right direction no matter what,
and would perhaps be useful without a complete rewrite.
I could work on render.cpp, a brand new sourcefile
that starts at the top of the js tree, the document if you will,
and traverses it, and builds the text buffer
with its hyperlinks and forms and such.
In any other browser this piece of software creates the display on the screen.
That would be something we will need, I imagine,
no matter what, in the future,
and would not disturb any of the existing machinery.
It's just there when we're ready to use it.

Circling back to ipc, if we stay with mozilla,
as chris suggests we should, and I'm really up in the air on that one,
but if we do, the fixed js heap will really come to haunt us
in an ipc world.
Right now we have the law of large numbers on our side.
All the js sessions together, under edbrowse,
live within a js heap of 128 meg or whatever you allocate,
and by averages that's pretty safe.
One instance might consume 50 meg but the others are all small.
Now if we spin off a separate process for each js,
we have to allow a heap of 50 meg for each of them,
and pretty soon js consumes all your ram, mostly for doing nothing.
Maybe that's ok in virtual memory,
where allocated yet unused pages just don't do anything,
but it really rubs me the wrong way.
I wish the js heap in mozilla was properly dynamic.
I suppose there could be one js server, in one back-end process to edbrowse,
that manages all the sessions,
then we benefit from the average again,
but if js crashes you lose all your js sessions,
but you still have all your edbrowse buffers.
Maybe that's a good compromise.

Lots to think about here.

Karl Dahlke