[PATCH v2 2/4] vbscript: Move the script context heap to the script dispatch object.
Jacek Caban
jacek at codeweavers.com
Wed Oct 23 13:16:02 CDT 2019
Hi Gabriel,
On 10/21/19 1:40 PM, Gabriel Ivăncescu wrote:
> The heap stores dynamic global variables added during the execution
> phase. We'll need to reference them in the TypeInfo, and so we have to
> reference count the heap itself, and the simplest way is to use the script
> dispatch object to store it.
It seems to me that you concentrated a bit too much at avoiding copying
the data rather than on root of the problem. It's possible to avoid
copying in different ways. The thing is that having to represent the
collection of global members in different ways for similar tasks
probably means that representation of the collection is not right.
Actually, we know that current global scope representation is not great.
A simple list was nice to have things done and working, but it's surely
not optimal. I don't expect you to rewrite it all, but it will be
eventually rewritten and it would be good to know that we're changing
things in the right direction instead of working on something that will
need to be rewritten for future improvements.
I don't know exactly how it should look like. It's even possible that we
will have to do some copies to capture the state after all. If I was
looking at it, I'd start with more experimentations. Your tests seem
like a good start. It would be interesting to see how things change when
you add more global members later. You tested that adding new global
variables doesn't change the existing ITypeInfo. How does the new one
look like? Does it append new variables after previous ones? What if we
added a new "dynamic" (non-explicit) variable? What if we mix it all?
How about functions? What do DISPIDs look like? Is it reasonable to try
to replicate native DISPIDs? Once we know more answers, we may decide
how the collection should look like.
Once we know that, we should consider how to replace existing storage
with something suitable for ITypeInfo. The new collection would need to
be available for the interpreter and script dispatch (its GetIDsOfNames
should probably share the implementation with ITypeInfo one).
script_ctx_t may indeed be a good place. Another option could be
ScriptDisp or maybe another new struct. Note that we currently ignore
the case of closed script engine in other places (with things like
if(!This->ctx) return E_UNEXPECTED; in GetDispID) and until it's a
problem for an actual application, feel free to do a similar thing
(preferably with a FIXME). If we have to fix it, script_ctx_t is
intentionally done in a way that would be easy to make it ref-counted.
For that, however, it would be nice to see how both ITypeInfo, script
dispatch IDispatchEx and VBS class instance IDispatchEx behave on closed
script engines. Then we can decide how much of it do we want to keep
after releasing script engine itself.
Thanks,
Jacek
More information about the wine-devel
mailing list