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 ECD2377D0D for ; Sat, 26 Dec 2015 01:10:54 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id l126so216743979wml.1 for ; Sat, 26 Dec 2015 01:11:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=0ozsLPNR/eWww5tgDKDDPqePANNmZIYbdCDKIHD9r2E=; b=yZupZ+9JFnORK5l/GnVBuPcxgz63lJh/hVwrb+p84kS4y9nExqP7u3bDcGMP7zZk7x B7i22FigPc0xK1s1zJ5DdIFq02maN1L8A0ujb/850C2GGhOFhM1Gk35K8GKMQEI+lf2V O8n/6pIQ+7s+fxCSPFzB8I8rSJn2JuFnQ8ma1rfZ7qyjgoPDtY/BP10f/xQHtC4AymqO PxozR/u8j9ZilZ+Dht9OtUL4XE4FNCsbdGhUWvmSV/WgJe7cvQx2/eDyElNv5KcotYZQ CuWGyTp2wq60UPrR91T/Cmg2AedUaqiw+w+WPs3yTnfNYgoRixYTdwHpZD3FzY5hSwT6 StDg== X-Received: by 10.28.68.214 with SMTP id r205mr17796950wma.23.1451121070720; Sat, 26 Dec 2015 01:11:10 -0800 (PST) Received: from hob.adamthompson.me.uk (40.77.155.90.in-addr.arpa. [90.155.77.40]) by smtp.gmail.com with ESMTPSA id kb5sm48039409wjc.20.2015.12.26.01.11.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 26 Dec 2015 01:11:10 -0800 (PST) Date: Sat, 26 Dec 2015 09:11:07 +0000 From: Adam Thompson To: Karl Dahlke Cc: edbrowse-dev@lists.the-brannons.com Message-ID: <20151226091107.GB3144@hob.adamthompson.me.uk> References: <20151123100928.eklhad@comcast.net> <20151225231811.GA3834@hob.adamthompson.me.uk> <20151125185147.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dc+cDN39EJAMEtIO" Content-Disposition: inline In-Reply-To: <20151125185147.eklhad@comcast.net> User-Agent: Mutt/1.5.24 (2015-08-30) Subject: Re: [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: Sat, 26 Dec 2015 09:10:55 -0000 --dc+cDN39EJAMEtIO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > 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 wi= th 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 Chro= me uses multi-process somehow. I know they use a different engine but there mu= st be some way to communicate this stuff if they're really doing things this w= ay. Cheers, Adam. --dc+cDN39EJAMEtIO Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWflmrAAoJELZ22lNQBzHOs14IAK8HvWCDUKnbNy79UI5UJFAk 32rBZFKLvQQoS82MWnWMCFoaBeMEk+MgdMiKD6KI++KXd13pP4hKRy0DwjDyu1km PXlCtb5aTxVaV5k2VJYBWe/7TFqeXhqyStbDmROmFGrK0Zhhclx3iO+bCVgoLggj 1FFwFhtVPSBuysac8gRtNY1zp0vsYRYekcuuvLrx0kt6vQbNjVWuwm9WGRED1kkj qe+XiRfGQC2wJpb7L2ZEEiAL7EwoWAo7AmiRX1vWf8vGNAQteHrR9YwMnmIIc1xt 50yoGEU0O1a4jQ7Mh3MdjKIxlCtOiUSKqK+50+zlU6+Op5Fg7hyHpri9ZAhYrv8= =BPx7 -----END PGP SIGNATURE----- --dc+cDN39EJAMEtIO--