From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by hurricane.the-brannons.com (Postfix) with ESMTPS id CDDEC78402 for ; Wed, 5 Feb 2014 14:10:23 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id e4so1049427wiv.17 for ; Wed, 05 Feb 2014 14:09:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=ajWpkWjXx2g25OXcZABA75rdxOlXOm9PbXoTcHRhoc8=; b=GF2TG03DMBJJO3SgfwVXrGmhPzS7GCi8bbcpplCbxJtgGBGQGPUGE9hr3qfPH2F4tW bs7vLdTMsAf6jQycLxUr1gkOMjrLvQ8NRZSJ7sqMEEpSn6Dk8rQLBzcRT2yhxCom3eX1 0Sjc30jjXTHfkumMONkbbZfaCkVC8qmY+3UvYDc57sepBrB6yFn+zJzBBKsN1/lyhyjd TAiEPAgqYeEfggyh5rH6qVeqZCfpp1OAES+AZ60XIdp6kpfHUHngJ9dP6el2qnU87iKh OQH6XmSenPyuHwgzne1UwuOm9idO1P78PpWVi8i+bHPe7HpeGxZgy+sD+Or0l48/bBZm RVYg== X-Received: by 10.194.170.167 with SMTP id an7mr3137840wjc.39.1391638189092; Wed, 05 Feb 2014 14:09:49 -0800 (PST) Received: from toaster.adamthompson.me.uk (toaster.adamthompson.me.uk. [2001:8b0:1142:9042::2]) by mx.google.com with ESMTPSA id ci4sm64876170wjc.21.2014.02.05.14.09.47 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 05 Feb 2014 14:09:47 -0800 (PST) Date: Wed, 5 Feb 2014 22:09:44 +0000 From: Adam Thompson To: Karl Dahlke Message-ID: <20140205220944.GQ32200@toaster.adamthompson.me.uk> References: <20140105085547.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140105085547.eklhad@comcast.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Edbrowse-dev@lists.the-brannons.com Subject: Re: [Edbrowse-dev] compartments X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.17 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 22:10:24 -0000 On Wed, Feb 05, 2014 at 08:55:47AM -0500, Karl Dahlke wrote: > There are two paths to javascript, > creating the global object in the first place, > and then activating js later, which always calls jSyncup > to get things ready. > But aha, raii won't work here. > jSyncup calls and sets everything up and returns. > Then all the other js functions are called. > Set the compartment via raii in jSyncup, and when it returns > your compartment is lost. This is unfortunate as it'd be a nice simplification. > We can only simplify things if there is a straight, > old fashioned "set this compartment" call, > that does not involve scope or distructors etc. > I don't know if such a function exists. > If yes then we can clean things up a lot. > If no then we can't. There is but it's being phased out (i.e. may disappear whenever the mozilla developers get round to deleting it, with the possibility of such a removal not being documented). In addition it doesn't check if you've already switched into this compartment so you could quickly find yourself building up a stack of equal compartment (pointers? not sure) which just eat memory and can't be freed as they're protected properties of the js context (I think). At least I'm assuming that's how things work since you have to leave compartments in the reverse order to that inwhich you entered them. I tried to work around the RAII compartment logic, but the thing exploded when I went back a page for some reason (NULL compartment property in the context or a different compartment to that of the global object or something). Anyway the only way to get things working without a larger rewrite was to just use the recommended (if not particularly nice in my opinion) RAII way of doing things. To be honest I'm all for cleaning up these calls, but I'd rather get all the good things we're doing at the moment stable and ready for release then work out what kind of rewrite is required to tidy up the Mozilla update. Particularly as I think there've been many major bug fixes recently which really should be released relatively soon. To do this properly we need to have some time when the code is stable and we can just test for any other major bugs rather than making huge rewrites. I also need to work out why the debian mozjs24d package causes edbrowse to just segfault on startup whereas a manually compiled one doesn't (still haven't heard about the compilation flags). That being said, my first version of this message caused Edbrowse to segfault (typing in too longer line I think), so maybe we need to look into that one as well. Cheers, Adam.