On Fri, Dec 25, 2015 at 06:51:47PM -0500, Karl Dahlke wrote:
> Imagine pieces of js running truly asynchronously of each other
> and of the main interactive edbrowse.
> Such pieces must run under different processes or different threads.
> That's how we leverage the operating system.

Agreed.

> Take processes first.
> This has two problems.
> First is the js pool.
> This is specific to mozilla but that's our engine for now.
> If each edbrowse window, roughly a web page,
> or even finer granularity perhaps, like a js timer,
> if each of these spins up a process to run its js,
> that process has to set its memory pool for the max js
> that that web page might consume.
> 99% of the time this is a waste, most pages having just a little js,
> but oh well, that's what we have to do,
> and after you have pulled up 20 or 30 web pages you are out of memory.
> Maybe duktape wouldn't have this problem but mozilla does.
> You need one pool to take advantage of the law of large numbers.
> Most web pages small, a couple big.
> 
> Now the other problem is that pages can be interrelated.
> The js on one page can vector through window.frames into the js variables in other page.
> No clue how we would do this, since it seems to violate the
> AutoCompartment rules of moz js, but let's say there's a way to get past that,
> then there is an even bigger mountain to climb if these
> exists in sseparate process spaces.

Yes, I can't remember the name right now but one *can* do cross-compartment
requests somehow. I remember seeing the code for this somewhere,
although that may be out of date like a bunch of mozjs docs.

> Remember that windows doesn't have shared memory so we can't just have a common
> js pool for all the processes.
> Sending messages around every time you need an outside variable,
> well maybe, but that's really getting complicated.
> I don't see this as promising.

No, that's going to cause some issues without shared memory etc.

> Next is separate threads in one js executing process.
> This is much more doable, except, again, if you're looking for
> true asynchronicity you have to ask if the js engine is threadsafe?
> Is the compartment and all the variables etc on the stack
> so you can switch from thread to thread and execute the js in each?

Yes, that's one of the reasons behind compartments etc.
In fact they have constructs to support this since I think firefox works with threaded js.

> I honestly don't know, for mozilla or for any of the engines
> we've been considering.
> We'd have to write some stand-alone tests.

Duktape looks small enough it could be made thread safe if we need to.

> Finally, whether threads or processes, we must remember that any http
> request has to vector through one instance of curl,
> one http server that mediates all our needs.
> Processes are impossible here.
> If you want separate http requests to be asynchronous of one another they ahve to be in threads,
> so they can access the same curl space, same cookies, same passwords,
> same agent, etc,
> but then we have the question of whether the curl calls are threadsafe.
> I don't know.
> More tests or research needed.

Yes, again I'm 99 % certain they are.

I'm also going to look into IPC mechanisms for Windows since I believe Chrome
uses multi-process somehow. I know they use a different engine but there must
be some way to communicate this stuff if they're really doing things this way.

Cheers,
Adam.