From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 364927884B for ; Sat, 6 Dec 2014 04:48:58 -0800 (PST) Received: from resomta-po-19v.sys.comcast.net ([96.114.154.243]) by resqmta-po-03v.sys.comcast.net with comcast id QCnA1p0095FMDhs01CnF7z; Sat, 06 Dec 2014 12:47:15 +0000 Received: from eklhad ([68.84.191.77]) by resomta-po-19v.sys.comcast.net with comcast id QCnE1p0071gep3001CnEo4; Sat, 06 Dec 2014 12:47:14 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: edbrowse/3.5.1 Date: Sat, 06 Dec 2014 07:47:14 -0500 Message-ID: <20141106074714.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=1417870035; bh=O+/e/3v3VBeXbS6CReFNj1/LspmmvQ8vQkPrPk1liI8=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=os+dc7xdQ3KY6I7uXDE3FFfNn8uc3m+8jo1MFHnPJpsaZ2wzMaNgtswUygqAQf0by JzfVP41BJ/z4tiGf/NEELAa0AW/a+j+z9YiX1CV8jZ9nY/xlRS1toBUA84ZILXa5Tt 4I3Gj11MUueagt8mkhhZNYonaLb/w121vKMmZsLT+e3Yk1itskS5ec41bD/XtzkVdE SAek3Y9isbH2ZE3Pc1SHNH8ut9hqF91Dh7b9kxsCaQJvpsbbLXiUfYUtl/ZYJ8mpLD ED4MPSwVUHy/3Mep0hez+Vx3CCqVW1+8QZ36HqSikVeHdiHGwZOyPFgBWI5fbQB7k7 YvBOi4wC0ut2A== Subject: [Edbrowse-dev] IPC X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2014 12:48:58 -0000 While Adam's arguments for a multi-process approach are compeling, I still wonder if that should wait for a future date. I guess there are two approaches: a complete rewrite that changes everything, and leapfrogs all the way to the end, or incremental changes to get us there. If we can move step by step, I think the ipc separation would be one of the last steps to take. Given our limited resources, just three volunteers working in spare time, I kinda think we should go incremental, though I realize there may be some jumps that just can't be done that way. I'm trying to think of a piece or two that I could work on, that would be a step in the right direction no matter what, and would perhaps be useful without a complete rewrite. I could work on render.cpp, a brand new sourcefile that starts at the top of the js tree, the document if you will, and traverses it, and builds the text buffer with its hyperlinks and forms and such. In any other browser this piece of software creates the display on the screen. That would be something we will need, I imagine, no matter what, in the future, and would not disturb any of the existing machinery. It's just there when we're ready to use it. Circling back to ipc, if we stay with mozilla, as chris suggests we should, and I'm really up in the air on that one, but if we do, the fixed js heap will really come to haunt us in an ipc world. Right now we have the law of large numbers on our side. All the js sessions together, under edbrowse, live within a js heap of 128 meg or whatever you allocate, and by averages that's pretty safe. One instance might consume 50 meg but the others are all small. Now if we spin off a separate process for each js, we have to allow a heap of 50 meg for each of them, and pretty soon js consumes all your ram, mostly for doing nothing. Maybe that's ok in virtual memory, where allocated yet unused pages just don't do anything, but it really rubs me the wrong way. I wish the js heap in mozilla was properly dynamic. I suppose there could be one js server, in one back-end process to edbrowse, that manages all the sessions, then we benefit from the average again, but if js crashes you lose all your js sessions, but you still have all your edbrowse buffers. Maybe that's a good compromise. Lots to think about here. Karl Dahlke