From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) by hurricane.the-brannons.com (Postfix) with ESMTPS id DB18177E69 for ; Wed, 4 Sep 2019 22:00:59 -0700 (PDT) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-09v.sys.comcast.net with ESMTP id 5jrSioIJ63mMa5jt9iiR3j; Thu, 05 Sep 2019 05:00:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1567659655; bh=0pfjwLFVZ6axnswUyNj2eYrYfaup0lQ8fpsFgW5e70M=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=HVIgaXOfdzPeYP0EtHs809YJMJ5KDzRM9GBcGtyN2rcMYsBDaYbp0NwOl/SbT21n1 w10kQAxWKPA6JmzBwURF8MH6z3MxGSJhFotfNlKogAd+A5Cmd/b6hgIPX5zkMkHkIy m/gqfuTzUIn7vseKCofyAtTXEdGqvh4tBBof957xifn4wVfAi/ZmdeFgvZpA6cHtwj 0PXBMShDJETKrgCHK9I77YpVs4s9w+V0gH6tKnW44WgW8Y7faLf4CLzr3UcsaPjeyp xTUIuzDttYpbI3ipqlAUpKt/X1bgHRzbLCUHh+p0whOF7XCX+Ye8I7L3Ze1/LdkUSL LJPRp69bktnxQ== Received: from unknown ([IPv6:2601:408:c303:3f49:21e:4fff:fec2:a0f1]) by resomta-ch2-04v.sys.comcast.net with ESMTPSA id 5jt7iviP7i3Ue5jt8iBVAt; Thu, 05 Sep 2019 05:00:54 +0000 X-Xfinity-VMeta: sc=0;st=legit To:edbrowse-dev@edbrowse.org From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E) Subject: [edbrowse-dev] timers and async Date: Thu, 05 Sep 2019 01:00:53 -0400 Message-ID: <20190805010053.eklhad@comcast.net> X-BeenThere: edbrowse-dev@edbrowse.org List-Id: Edbrowse Development List Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=nextpart-eb-580642 Content-Transfer-Encoding: 7bit This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --nextpart-eb-580642 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This is just me thinking out loud in the middle of the night; you can = ignore it. Now that threads work and we sort of understand them, what can we do = with them? Javascript does some stuff using timers, and I already have to throttle = them back so they don't run every 50ms or whatever, cause I'm just not as fast as chrome with its compiled js, (yes = compiled), and I'm never going to be that fast, so high speed timers push the load average up to 1 and literally lock = you out of interacting with edbrowse, and ok let's assume that is done - still - sometimes a timer runs and does an xhr, and you hit return, and you = have to wait for that timer to finish before you get anything. Maybe it's just a second or 2 but it feels weird. worst case, server could fail and you wait 20 seconds for the http = connect timeout. What if the javascript timer ran in another thread? You could look around and read the site, just like a sighted person = could see the screen while more stuff was happening in the background. Ok but there are some problems. duktape is not threadsafe, it says so clearly in the programmers manual. One and only one thread can run js at a time. The next timer does not run until the last one is finished. And you can't run js in any way until the last timer is finished. In jdb, the expression you want to evaluate doesn't happen until the = timer is finished. Pushing a button, even typing an entry into an input field, has to wait, because that field might have oninput or onchange etc that runs = javascript. When you try to do any of these things I call a blocker to wait for the = timer to finish. Well that's no worse than we are now, because if a timer runs in the = foreground you have to wait for it to finish before you do *anything*, even read the page, so we're not giving up anything it's just some = really careful programming that could lead to subtle irreproducible = bugs, and has a whole bunch more code that has to run in a background thread, = not just curl and httpConnect. Is all that worth doing? Probably not, timers run fast and you usually don't notice, but here's = another thing. Some sites have asynchronous scripts. They can run whenever, maybe pulling in ads or analyzers or metrics or = whatever, and you shouldn't have to wait for them. Right now they are just scripts, and they have to load and run before = you see the page. The easiest way to implement an asynchronous script is to put it on a = timer and let timers run asynchronously. In other words, if I had already implemented timers, then async scripts = would piggy back on that. You wouldn't have to wait for the script to run, or even load! It just goes in the background and you look around at the page, and = yes, after the script runs the page might change, and edbrowse will tell you, and you can look at the lines that changed, = or not, as you prefer. If on a timer, these scripts would run *after* all the onload code, and = I don't know if that's right. I mean I might spend a month implementing all this and feel good about = it, and then that one site comes along with an async script that can run separately from the other scripts, but still has to run = before the onload code, and then I'm screwed, cause we have to wait for the script to run = before the onload code, before you see the page, and all that work didn't gain us a damn thing. So it would be nice to *know* if async scripts can run after the page = is loaded, and after the onload code, but I don't even know how to ask the question. More complications: if a timer or async script is running in the background, and you do something heavy handed like ^ or q or ub or et or rf or = something that tears down the entire window, that timer has to finish first, or it will be operating on structures = that have been freed, and you know that will lead to seg faults. Ok that's enough rambling for now. Karl Dahlke --nextpart-eb-580642--