From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 76B7877D0D for ; Thu, 24 Dec 2015 05:15:26 -0800 (PST) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-07v.sys.comcast.net with comcast id xREd1r0042Fh1PH01RFe5S; Thu, 24 Dec 2015 13:15:38 +0000 Received: from eklhad ([IPv6:2601:405:4001:e487:21e:4fff:fec2:a0f1]) by resomta-ch2-08v.sys.comcast.net with comcast id xRFe1r00E2MDcd701RFe0p; Thu, 24 Dec 2015 13:15:38 +0000 To: edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke References: <20151123100928.eklhad@comcast.net> <20151224111913.GA5501@hob.adamthompson.me.uk> User-Agent: edbrowse/3.6.0+ Date: Thu, 24 Dec 2015 08:15:38 -0500 Message-ID: <20151124081538.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1450962938; bh=DxiKi/V8AdTmDEQ2gCphBC0117Z4tKzK4JbQX9qSNK4=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=g6vqPKAw4iVWYGs/q3dSP3BJjw09XrHeyH8iJbWvxvJI9pL3YKc0001OjMVtp52Rr z5eRpxkbohYSvx5SdTw0L5jxQ5pc6UwErQCbPEgqz6PZU0/r/FRiqNkA65m0Jc48bs uf65vrM6iNgfHyb+pveuRSPb0NS50s0kWCzt0xHy6IzleOiuEd8xeTIP+WJXreeRRc 0PUsSeOuRRJmhNWknPYwD4T0sPX1+Tph9yrYUBsA7C5ln6Z46NUDNZn99lrrKdgnoI AgQrtwkHoWSSkhN7lQVR8i08CNVScuw/GHs76j1QFecj6uB6SvYpbwMnXh0WlS7GGw v843k37C+8YWw== Subject: [Edbrowse-dev] One program Two processes X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2015 13:15:26 -0000 > Also, we're going to *have to* make js run asynchronously one of these days Well I hope we don't, in the most literal sense of "asynchronous", Because it's 10 times harder. Here's what I mean. Let http requests run in the background, truly in the background, in parallel with everything else, because these are the only tasks that might take more than a millisecond. We already do this with our background downloads, and it is truly asynchronous. When a request is complete, from xhr for example, then a piece of js could run, serialized with other pieces of js and with edbrowse itself. Separate instances of js never run together, and how could they? Think AutoCompartment in mozjs 24, which puts you in a specific context. So js from two different windows can't really run in parallel, it all has to be serialized, this chunk running in this window in this context in this compartment, now that chunk in that compartment etc. It has to be a timeshare system, which is better for us anyways, easier to design, ammenable to messages and pipes, and *much* more threadsafe if we go with threads in a process. Timers work this way now. It looks like they're completely asynchronous, and they work just like they're suppose to, but in reality it's timeshared to keep the code simple and the interactions down to a minimum. A snippet of js runs under a timer, or some js code runs on behalf of edbrowse, or edbrowse itself is editing or formatting or posting or whatever. All serialized. The big test is http://www.eklhad.net/async run three of these in parallel and edit something in buffer 4. Timers queue up with the work you are doing but it all serializes, so when a timer fires in buffer 1, js runs in context 1, including AutoCompartment on the js side, and then it finishes and something else happens, and the buffers and js and doms don't get mixed up, and they don't get confused with the work you are doing in buffer 4 in the foreground, and this was a fair piece of work to get right and it's not trivial, but now that it's timeshared I'm pretty confident the windows and contexts won't collide. Oh another test which I have done is to run async as above but in the same buffer edit or browse something else on top of it, which pushes async down on the stack. But it's still there and its timer still runs and when you use your back key to go back it has the right time on the display. This timeshare approach keeps things manageable, and I hope we are able to continue with it. It also makes the one process design at least feasible, which we can continue to bat back and forth. As for xhr I would probably create a mock timer that fires 5 times a second and does nothing if the background http is stillin progress, but if it's done then the hxr js snippet runs, under the timer, and the timer deletes and goes away. It keeps everything timeshared as above. At first this design seems awkward and contrived, but it might be a bit like democracy, the worst, except for all the others. If we do retain our two processes, or even more, it would be easier if they were the same image, as they are now, and they just do different things. We tried to keep edbrowse-js lean and mean but found that it needed 30%, 50%, 60% of edbrowse, so now it's all there, with a global variable that reminds us we're really the js process. cmake under windows really works better if each sourcefile is mentioned once, as Geoff explained to me, so putting things together in libraries, no problem for two processes but becomes combinatorially difficult for more, so again one image is easy. Only down side is you can't even build the basic edbrowse without the js library. That is a downer, but fortunately Chris maintains statics so people can run the program even if they have trouble building it for any reason. And we don't have to make our libraries shared or dll, one image on disk and in memory, just running different ways. > I think that maintaining two concurrent DOMs is only sustainable to a point. I think we'll have to forever, in that we want edbrowse to browse even if there is no js, yet when js does run it mucks with the tree directly with native methods and that tree changes line by line, moment by moment, before we can resync with edbrowse. Anyways it's not easy no matter how you slice it. Karl Dahlke