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 977D877D0D for ; Thu, 24 Dec 2015 03:19:09 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id p187so179768881wmp.0 for ; Thu, 24 Dec 2015 03:19:22 -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=3Ct4FUdpvF7mY/y5W7eOuJpv/7mMdniO1GsNkorlRT4=; b=AGzQqEqpwzST19dlQGAily9b0N2MEtH/3hzZjsLEoEZlwX3+79FzbfT6KcLJcSyile s8cqd46nbl1ILGzLc15bzhORRSyiwguUrHDN656FVoCHVpEljZLgVOXm9LZ2W0Lktkox m6a7NGcUKYZjbNjrxtvtNHno6i/s9OR1dICo0FNIlKpAOCXNLVLj32uH3+DDtafItgPX CSWSV+wJLjpxRx6Be+mYLmc4PpkEhh5a+gO6kqx2LpfOWp0k9JjHB/qyICSVbIDN21EP KxLvG8bD0Vi7dweQ/JoH26nbK5tdOMO3fRhudWAllVG0o/SvYwE7wciZMkWfEbGgkN41 DENQ== X-Received: by 10.28.134.142 with SMTP id i136mr37379662wmd.86.1450955961019; Thu, 24 Dec 2015 03:19:21 -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 f205sm4170620wme.4.2015.12.24.03.19.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Dec 2015 03:19:20 -0800 (PST) Date: Thu, 24 Dec 2015 11:19:13 +0000 From: Adam Thompson To: Karl Dahlke Cc: edbrowse-dev@lists.the-brannons.com Message-ID: <20151224111913.GA5501@hob.adamthompson.me.uk> References: <20151123100928.eklhad@comcast.net> <87zix1djh4.fsf@mushroom.localdomain> <20151123154450.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline In-Reply-To: <20151123154450.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: Thu, 24 Dec 2015 11:19:10 -0000 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 23, 2015 at 03:44:50PM -0500, Karl Dahlke wrote: > > The biggest concern is that we have to share a whole bunch of > > HTTP-related state across process boundaries. > > Multi-threading sounds like the answer. >=20 > Yes, and the existing message serializing protocol > should prevent the kind of threading nightmares that we've > all experienced in the past. > One thread runs while the other waits. Not necessarily, there are lots of globals and static buffers in the curren= t code base, any one of which is a potential threading issue. Also, we're g= oing to *have to* make js run asynchronously one of these days and then all= the assumptions about the synchronising nature of the protocol will go out= the window. If we're multi-threading based on those that's going to make a= difficult task even harder. In addition such segfaults are horrible to deb= ug usually since they tend to be difficult to reproduce (i.e. due to timing= issues etc). > > wrap all of our networking code in its own process. >=20 > Pipes everywhere, looks like a mess, > and where does it end, how many more processes? > Remember that IPC is limited on windows. > I think this creates entropy, whereas one process would probably work jus= t fine. No because we're going to have to pull comms out anyway eventually in order= to get async networking which is increasingly required. Managing this by encapsulating them into a (possibly completely thread-safe= and thus multi-threaded) comms manager makes a lot of sense in this case. > > allowing edbrowse-js to call into the main edbrowse > > process to make HTTP requests? >=20 > We thought about this one before, > when we first learned js had to parse html and create corresponding js ob= jects > right now, as a native method, before the next line of js ran. > Those objects have to be there. > So native code would have to stop and send a message back to edbrowse, > but it's waiting for the return from running the native code, > it's not waiting for a message that says > "hey hold up and here's some html and parse it > and then call me reentrantly so I can create those javascript objects > and then we unwind the stack together and hope that the reentrant calls i= nto js > have not disturbed the thread of execution that was running, > which I can't guarantee for edbrowse or whatever > js engine we're using this week or next week." > Anyways it was way to convoluted, and much easier > to make sure both processes had access to tidy and could do that work. > In the same way, both processes, or both threads, > as you prefer, now have access to httpConnect for making that call. Actually, although this was a quick fix, I think that maintaining two concurrent DOMs is only sustainable to a point. Since the interface is going to have to become more asynchronous anyway, this should not be so much of an issue in future. > > Does js really need to have direct, unmediated access to HTTP, >=20 > It needs to make the http call before the next line of js code runs. > A native method that does not disturb the flow of execution. Actually that's incorrect. as far as I know, although synchronous calls are implemented on top of it, AJAX is fundimentally asynchronous, event driven, networking. That's what the state variables are used for. Hence the Asynchronous part. If we keep designing as if the world of the internet is synchronous then fi= xing our design to be asynchronous is going to become increasingly difficult. Regards, Adam. PS: I'm also going to look into portable IPC options to replace the pipes e= verywhere mechanism we're currently using. --4Ckj6UjgE2iN1+kY Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWe9SxAAoJELZ22lNQBzHOAIUIAIW6F2hUwFtBGJiMG05BUnfd vhkomq7ur9yQQXIWpPpz/x/q85HB5HG7qZxhzFCYP+A0xV8XNnc3TRv3jIZs5mA8 +Hdo6J+O70VtZsqzMLtHqy7E6gxMOuS0BVgBtDFWmabkjgAwN2BOl0dR9ECRISsu RBFbp4yBncTN3/PHeLcc1mXLgnTdlgMLPZdaek6ueQ+lwF0miXjGl1DTA96z/BaS uw94aLT8Yy932P/pBnaQ2qWO8wzFBd1wlBh/aSCFwD2rtAGWYBxwlLeg0HLnFHAS 6XBudtDrj22s0mB6AHJxNGX8c2dtk278/wR1ufcogc9oE0xZOPP9G+LuiSnce/g= =FLpb -----END PGP SIGNATURE----- --4Ckj6UjgE2iN1+kY--