Re: [Edbrowse-dev] JS1

[Adam Thompson <arthompson1990@gmail.com>]

On Fri, Jul 28, 2017 at 01:39:10PM -0400, Karl Dahlke wrote:
> > 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.

They're kind of authogonal and kind of not.  With the separate process we can
keep spinning round the main input loop even if js is stuck in some expensive
operation... I can switch buffers and get on with browsing whilst the page in
buffer 1 does its thing.  We can do that by polling a pipe or switching to some
non-blocking IO.  With js in the same process we've got to either spin it up in
a separate thread (inwhich case anything which interacts with the main edbrowse
ui has to be thread-safe) or the browser grinds to a halt when someone puts an
ill-advised loop into their js.  If we can find a way to make the code
thread-safe or get duktape to do collaberative multithreading (i.e. stop after a
certain amount of instructions to allow us to spin round the main loop
again) I really don't mind, but it's just something to think about.  It'd be
nice to simplify (if not altogether remove) the code to sync the edbrowse and js
worlds however.

If I can get some time in front of a computer this weekend I'll have a look at
how much work this'll be to make happen.

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

Same here... lots of ways things could go badly wrong!

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

Yeah, that's a good example of how this stuff can work.

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

Agreed, I'm particularly worried about websites' increasing reliance on AJAX
being genuinely async and then there's websockets (which'll have to happen
sometime... unfortunately).  I know we can multiplex sockets and that'll work
well but it'll be complex.

Cheers,
Adam.