[Edbrowse-dev] IPC

[Edbrowse-dev] IPC

[Karl Dahlke]

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

Re: [Edbrowse-dev] IPC

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 4953 bytes --]

On Sat, Dec 06, 2014 at 07:47:14AM -0500, Karl Dahlke wrote:
> 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 can see why, but I'm worried of incrementally heading in whatever direction
we need to get the current increment done.
I'm not saying we need multi-process tomorrow,
but that's where I think we need to be heading,
and if we increment in that direction then I've no problem with an incremental 
approach (assuming everyone's agreed on this as the final outcome).

> 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.

I'd rather render.c which'd be a proper DOM implementation which can then be
plugged into by whatever js machinary we use (whether it be in C,
C++ or whatever), since I'm concerned that if you go down the js document tree
route we'll end up tied to a particular js engine implementation.
Better still, I'd really like it if we could have a module which handles display, and modules which handle what to display e.g:
the display (or ui) module handles how to render a line to the screen (including support for hyperlinks etc)
We then have a module which handles text, one which is a browser implementation, an email implementation and a database implementation.
This is somewhat like we have now, with the difference being that I'd like to increase the separation, with a future idea to be plugin support.
To get there incrementally, it'd be good if we could work on separating what we already have into such a display module (personally I'd prefer to write it in c rather than c++ but whatever) and see where that takes us.
Going back to the philosophy which has been talked about in previous threads,
what'd be really nice is an interface library which handles commands and
displaying etc which can then be used by software wishing to provide an
edbrowse like ui (yes, I've wanted to do this for other projects before).
This is probably not that plausable,
but if we can head that way with the code I think it'd make things easier to 
work on (i.e.
clean up the code and separate things where we can).

> 
> 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.
Yeah, that *SUCKS* a lot. As I said,
this is going to be hard and won't happen quickly.

> 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.

I toyed with this idea but there has to be a nicer way.

> Lots to think about here.

Indeed, and I think we've got a bit of time to discuss things.
I'd rather know where we're headed than start heading there and discover we
were heading to the wrong place half way.

Cheers,
Adam.
ps: when I've got a bit of time (over christmas probably)
I'm happy to investigate how separated the UI and backend code is and what it'd
take to increase this separation if we want to.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]