From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 76BFB77C83 for ; Tue, 22 Dec 2015 16:12:03 -0800 (PST) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-03v.sys.comcast.net with comcast id woBZ1r0032JGN3p01oCC2M; Wed, 23 Dec 2015 00:12:12 +0000 Received: from eklhad ([IPv6:2601:405:4001:e487:21e:4fff:fec2:a0f1]) by resomta-ch2-10v.sys.comcast.net with comcast id woCC1r00E2MDcd701oCCol; Wed, 23 Dec 2015 00:12:12 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: edbrowse/3.6.0+ Date: Tue, 22 Dec 2015 19:12:12 -0500 Message-ID: <20151122191212.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=1450829532; bh=8g7KjlcKDXpugZJYHnSENpJ8DCkOwTb3GzelJN//404=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=N0alnlO4+c4YbI3dJkzW9vsrnJEv/f9CpbP5/LGDU0j6auoI3qScfu1ZXJ9v+dbIV 24K5p0wA/tdTk2mmscw/0hBCu7gIFtj0r4SfExGjSKnrlYYXq4WImO/vyTItHUWErJ UKpbchMJqIbd0ZBPg6tpIHM1WRkPaJ9hDcQkCHhjuHWB3pV54D8vZljFq4RG8EmCX8 FdCFM5+DKxey9r9kusr+a61L7Ny1Wij8iZgp9YNG2HYN/uTUyL+2m6XtVOB7cTQc0+ ZpeMr3xKCQoB73dCmegnY5Y11bPBWnPmIV95yKunEn+YXAx3eiJRtDWopj1Mqozjp+ x5FieTGBQMXmw== Subject: [Edbrowse-dev] One Process 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 00:12:03 -0000 I really think all of edbrowse should roll back into one process. Keep the js stuff in its own thread, with the same message interface, but you don't need interprocess pipes just global structures and some kind of wakeup semaphore or whatever the thread package offers. A big advantage of the separate process was when js went down you didn't lose all of edbrowse and your edit sessions etc, and I get that, but edbrowse-js is pretty stable these days. If anything edbrowse crashes much more often than js. So I don't think that's a big consideration any more. On the other side, I just wrote, in the last email, about dynamic changes like web authorization passwords that would have to pass down via messages, whereas one process with one address space would obviate that need. And the config file would be read once, and so on, but those are small, here's the big thing. If curl is used in the js process, either directly or through my http routines, we have two instances of curl running, both messing with the same cookie jar. We've written before about parallel instances of edbrowse clobbering each other's cookies. That's why we typically run one edbrowse with lots of parallel sessions open, one curl, one cookie jar. But now we have no choice, two processes, two curls, and worse still, they're hitting the same websites. edbrowse will call the site and have a cookie set, perhaps the session cookie that makes the rest of the sesssion work, but the curl inside js doesn't have that cookie. So when it makes an http request to that website the request won't work. In other words, we may need transient cookies common to the two instances of curl, which there is no easy or practical way to do. So I'm thinking pull everything back together into one process. Believe me, we have not wasted time or energy because of the separation. The two process design has forced an interface, an API, between edbrowse and js, and we needed that. I think that is responsible for the stability of js that we now enjoy. But this can be retained, even if we meld the two processes back together. We keep all the messages going back and forth between threads, the same interface. I think the cookies, transient, and the ones in the jar, will force us back into one process. The logic seems inescapable and unassailable to me. Just a matter of who wants to take it on, and when. Karl Dahlke