From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (71-34-72-125.ptld.qwest.net [71.34.72.125]) by hurricane.the-brannons.com (Postfix) with ESMTPSA id 42EFB77C83 for ; Wed, 23 Dec 2015 11:59:24 -0800 (PST) From: Chris Brannon To: edbrowse-dev@lists.the-brannons.com References: <20151123100928.eklhad@comcast.net> <20151223184500.GB2992@hob.adamthompson.me.uk> Date: Wed, 23 Dec 2015 11:59:35 -0800 In-Reply-To: <20151223184500.GB2992@hob.adamthompson.me.uk> (Adam Thompson's message of "Wed, 23 Dec 2015 18:45:00 +0000") Message-ID: <87zix1djh4.fsf@mushroom.localdomain> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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: Wed, 23 Dec 2015 19:59:24 -0000 Adam Thompson writes: > A sort of multi-process multi-threaded mechanism. 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. Take that state that needs to be shared across threads, and encapsulate it behind a well-defined interface to insure proper synchronization, consistency, etc. We will have to be much more careful about the use of anything global. Another solution might be to wrap all of our networking code in its own process. Let the edbrowse, edbrowse-js, and other processes communicate with it using an API based around messages exchanged over pipes. Again, this insures proper and synchronized access to this huge blob of global state. Or how about allowing edbrowse-js to call into the main edbrowse process to make HTTP requests? Does js really need to have direct, unmediated access to HTTP, or could it send messages over its pipe to the parent process saying "GET ", "POST ", and so forth? -- Chris