From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 25A8477BBB for ; Fri, 28 Jul 2017 12:50:50 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id t201so133862975wmt.1 for ; Fri, 28 Jul 2017 12:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=jI8HH/4jqzG/l21hH84etQxVT9FTRSmlFQ+OzplzFv8=; b=feRFm1xkJoReoEsaQ52U5NTBGxk8kCSNwQCqONk3jOz+gKEwr7wIk3Y+rPYxhBEmYq 67Q72dkoS8krHwEvwH8ETul9qAgibcW5lBgygWc1GcHprJ2f/BfU93/esN6Xa//EPGAv HgcbVcpbi7WKa7mDQoIeJFSukALjeI37hInuqXw1igHr4/5tkkydq/sHEuYWj+FNW8zT pCs9LL7PCGIVf2uu+esxTwNxrIZcMjnOf8JL0QMqbwqSqBvOHcPYjFZEz90OYXtCntqd brKA7oZ/tNeG89Lk435Gc7gaZAC+0BuH1Bt6nzCKYPliBmSLlz+j8QyXZ49ewwz6+90c ty8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=jI8HH/4jqzG/l21hH84etQxVT9FTRSmlFQ+OzplzFv8=; b=c72qHW+88YOhNEVsyZaBDI7ipTEhbxL/Cn0HJ/1A1v20ePzbIYLDPtOdT0N/CfW9y7 +fmmNK4nbT4Lu+qsr83f1LCtEwg4ZVvd/78S+aRpTVvuui5vCL2aDtCrkKE+91NxmW21 WfTlhONjtNZj8H1v+zr8SjdmUXErgZCpoHP6qPwMIvmlgDjRCshjgVAPPBNOiCZLsX4b sdRR1IltspIpTRkLMJyeE50B4g4hYNonu5C6xVI9aU2VVGgwF4Ll8dc5UfTvI80xjO94 1ckyWQ+56HCFjfMKHvoy+PiI0bNrT76RZslGMCBnWq+K6ftUdQtW/R9C5ZDmtDCm2wZp g3UA== X-Gm-Message-State: AIVw110d1F7KjJhn2cBqeysWU5LzW6ZGvoTQIaaj3R4NgEI/vqVdbhcT bbPABB7y5Z40Vg== X-Received: by 10.28.184.87 with SMTP id i84mr6554731wmf.22.1501271470545; Fri, 28 Jul 2017 12:51:10 -0700 (PDT) Received: from odin (odin.sdf-eu.org. [178.63.35.194]) by smtp.gmail.com with ESMTPSA id b186sm16226745wma.24.2017.07.28.12.51.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Jul 2017 12:51:09 -0700 (PDT) Date: Fri, 28 Jul 2017 19:51:03 +0000 From: Adam Thompson To: Karl Dahlke Cc: Edbrowse-dev@lists.the-brannons.com Message-ID: <20170728195103.GE20415@odin> References: <20170622224940.eklhad@comcast.net> <20170724175751.GC20415@odin> <20170628133910.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170628133910.eklhad@comcast.net> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [Edbrowse-dev] JS1 X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.24 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 19:50:50 -0000 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.