From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 4938277FF6 for ; Sat, 22 Jul 2017 19:49:32 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-11v.sys.comcast.net with ESMTP id Z6xOd5CMFZ4XSZ6xhdGQrK; Sun, 23 Jul 2017 02:49:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1500778181; bh=tyFLrdvp1iIGcYkq2Ey2x36dJ8HZZMR80TniFy5YygQ=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=TAmt4ausVN91pWao/4hUf2+DYIphg2ImBwirF0MBw1Rez8i0R+TkyHrPg8Ir8jLBe hD6ecJWLUtNzM2YcrQGVyYdGmFKR6VEccgqxyhZHj7/n7Yo8eak1QqCMtOugNbJvuL GGdXUZbef8RokOMVIjD4byHhjL3ETFm8fngqGA/aJDsGbTWj/9+zuQJWgIfa7B+M5J 2iXtiJ4GrxjI/mhZ9MryaYBbhSkshUNAdgFL+bszRvH4ZtcD+8GY+WTHHR0shFZD7i UzCnVulz3cOX35Sxz8juj1nuvh8pSge6ic2pitkejXm+bviwm9WyVgQA7CjHF9xq5c U183EStddX5uw== Received: from unknown ([IPv6:2601:408:c301:784d:21e:4fff:fec2:a0f1]) by resomta-ch2-19v.sys.comcast.net with SMTP id Z6xgdOYV77sC9Z6xhdCzrC; Sun, 23 Jul 2017 02:49:41 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: edbrowse/3.7.0x Date: Sat, 22 Jul 2017 22:49:40 -0400 Message-ID: <20170622224940.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=nextpart-eb-097115 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfPb1OAi7IEfeX1ev6cG6jM0YxYHgvMbMslIePleipK34tvi7xJnUXSP3cKBsVAjCUhkOWi0dch2M4WWiHjinkvchbs4ysNF3ksSe7Nel0WqCMpOlmKI+ sI3Ui1guxLk09n7XHK+D0z6cinwwuuwKUx14KkItZwFn0yJrqgMzFEZY Subject: [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: Sun, 23 Jul 2017 02:49:32 -0000 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-097115 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This is either for fun, or for testing, or for the future. I'm not sure. export JS1=3Don Set this to any nonempty value, and edbrowse remains one process. It = doesn't fork off a copy of itself to manage the js. The default is as it was, 2 processes and pipes. The first implementation of this feature was easy peasy, almost too = easy. Leave all the pipes up and don't do the fork. Send messages through the pipes and back around to the same process. After edbrowse has sent a message to js, and is waiting for a response, = it does this. whichproc =3D 'j'; processMessage1(); whichproc =3D 'e'; processMessage1 is in jseng-duk.c and it reads and processes the = message and writes the response back to the pipe, back to edbrowse. So it looks like the other process ran. whichproc j or e makes the single process believe it is running as the = js process then as edbrowse again. If you just joined us and looked at the software, and thought we = routinely ran as one process, you'd think it was the stupidest design = ever. Sending messages out through pipes and back to myself instead of just = calling the functions that are right there. But it's evolution, isn't it? It reminds me of the gene that manufactures vitamin C, the gene that = works in most animals, but not us. It's broken in us, it's still there but broken, so we have to eat fruit = or die of scurvy. But I digress. This worked for jsrt and all my local tests, but not in the real world. Websites can have large strings, and these can be part of the messages. When you push a long message into a pipe, it blocks until somebody = reads part of it from the other side. That's how pipes have worked since 1980. With nothing asynchronous reading from the other side, everything = stopped. Oops. So I bypassed the pipes and put the message in memory. Then the other simulated process reads it from memory, writes the reply = in memory, and so on, and that works. It's still a modest change, and only comes into play if JS1=3Don. For nearly 2 years Adam has told me we should stay with 2 processes, = and so far he's been right all along. When js crashes, and it still crashes a lot, at least you keep your = websites and the book you were reading and the email you were writing = and so on. And of course the 2 process messaging API is great encapsulation, and = meant I could switch from mozilla to duktape in 3 weeks instead of 6 = months. All good, but the separate processes and spaces cause trouble. Keeping a consistent set of cookies in the two curl spaces is not easy, = and I'm still not sure we're doing it right. You can test it with JS1=3Don, one curl space, and see if the website = renders properly. Or consider the code Dominique is working on right now, the domains and = passwords for 401 authentication. He wouldn't need to do any of that if it was one process. But it's two, so he has to write code to pass all that stuff in = messages through pipes and down to the js process. Well before any of this is written he can test it in one process to see = if the authentication works for both edbrowse http fetch and js http = fetch. It's a way to compare the two worlds. Wil one process some day be the norm? Wouldn't change the user interface, so it's entirely up to us. Maybe someday, and boy could we simplify the code! But not until js is rock solid and just plain doesn't crash. We're not = there yet. Example, we call tidy to parse html, and we don't feel like we need a = separate process and pipes to do that, because tidy doesn't crash. Karl Dahlke --nextpart-eb-097115--