From: "Gabriel Ivăncescu" Subject: Re: [PATCH 1/9] vbscript: Add script TypeInfo stub. Message-Id: <6b59d7af-0f98-7caa-c372-726345c6b4c9@gmail.com> Date: Wed, 16 Oct 2019 17:42:46 +0300 In-Reply-To: References: <67326619-6809-4787-5bff-7c428796f216@codeweavers.com> On 10/16/19 4:16 PM, Jacek Caban wrote: > Hi Gabriel, > > On 10/16/19 1:52 PM, Gabriel Ivăncescu wrote: >> And the context changes are not reflected by earlier typeinfos, so the >> duplication is necessary, each of them is "frozen" at the moment it is >> retrieved > > > I'm not convinced. Note that we currently store functions and variables > in lists and always add new members to the beginning of the list. It > means that you may treat each element of the list (head is the most > interesting element) as an immutable (or "frozen") snapshot of current > context. Storing current head of variables and functions lists in > TypeInfo should be enough, AFAICS. > There's several issues with this. First, the script engine itself can be closed and released, and in this case, the lists will get released as well (the code has asserts about this behavior when the IDispatch ScriptDisp gets released). This is why I copy the strings to the TypeInfo's pool. Also, the variables need to be stored in reverse order compared to how we compile them, and separated by const/non-const to match Windows in terms of their indices. I think this may be important because you can use GetVarDesc to retrieve it by index. BTW, we cannot store a pointer to the head of the list, because we need to random-access them in GetFuncDesc/GetVarDesc by index. I also think this index must match Windows. Some applications loop through them with indices (from 0 up to cVars from the GetTypeAttr). At least creating an array is necessary so this process doesn't have non-linear complexity... > > If you need something more sophisticated, it should be possible to > change how we store the context in a way that we could retrieve such a > snapshot easily. I can imagine compiler storing global functions and > variables in a separate collection that is immutable. It would probably > have to be recreated whenever something changes (which is rare), but it > could be efficiently use across vbscript. > So one giant pool for everything? The problem in this case is, what would be the best way to release it properly? We'd need some sort of reference counting at the very least, so that releasing the ScriptDisp doesn't also release the list if there are any TypeInfos holding it. Which would complicate things a bit. Is that something like what you're thinking of? Thanks, Gabriel