From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) by hurricane.the-brannons.com (Postfix) with ESMTPS id C32A977C83 for ; Fri, 25 Dec 2015 15:51:32 -0800 (PST) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-12v.sys.comcast.net with comcast id xzrh1r00126dK1R01zroq3; Fri, 25 Dec 2015 23:51:48 +0000 Received: from eklhad ([IPv6:2601:405:4001:e487:21e:4fff:fec2:a0f1]) by resomta-ch2-01v.sys.comcast.net with comcast id xzrn1r00e2MDcd701zroJ1; Fri, 25 Dec 2015 23:51:48 +0000 To: edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke References: <20151123100928.eklhad@comcast.net> <20151225231811.GA3834@hob.adamthompson.me.uk> User-Agent: edbrowse/3.6.0+ Date: Fri, 25 Dec 2015 18:51:47 -0500 Message-ID: <20151125185147.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=1451087508; bh=oqn2Lmi0cTdo5SR3CxMXcRn78cWzCvACqaq0/o6QZ/A=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=IQuvnPMnrTsvBbt9NmRMVi57M/ztSBU46sgvs9GnXkrGp+5wLbJD63ytIpxXaBJN4 uuL4H8sH5jxjTlHcs5fkF83Yh1uvbuS3RFvxTzMkJl8+P/UYw4YVAyPk6S3o/lNl1M cqlMimZkFCuxETEwRUvII7ijGrvujOGQVGHUiIPZuMadhNUoKurglGZXuOIyHFpe3r pA2tyMrXLRsat8grJMGuZa0CH7un2VjWCNSu/yntEvUWQjv0OoTERYdDnN24rSq1km YTprtPw1Ukee86PT3ErJuwcPKNdn9YzIhorhSXxwVPgxHMDx2k3qvk17PJIoJZrn1Z Jp7MTLHvmYJCA== 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: Fri, 25 Dec 2015 23:51:33 -0000 > the underlying operating system can handle that stuff. That's the hope, so let's track it down a little further. 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. 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. 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. 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. 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? 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. 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. Karl Dahlke