On 5/5/17 4:09 AM, Henri Sivonen wrote:
On Thu, May 4, 2017 at 7:39 PM, Nathan Froyd <nfr...@mozilla.com> wrote:
I think you could possibly make your things a WebIDL interface, which
don't require refcounting, and magically make the WebIDL interfaces
work with XPIDL, but I do not know the details there.
I'll keep that in mind. Thanks.
I'm not sure this is going to work in this case. WebIDL interfaces that
don't require refcounting basically require that the JS object owns the
C++ thing; it will delete it when finalized.
You could do non-virtual no-op refcounting. But you still have a
problem where ToJSValue only knows how to work with subclasses of either
nsISupports or nsWrapperCache, both of which involve virtual functions.
If I can take a step back, though, you have the following requirements:
1) The same Encoding* has to lead to the same JS object. This means
you need either a global or a per-compartment (depending on how your
object behaves in terms of cross-compartment wrappers) mapping from
Encoding* to JS object. We have automated machinery for both versions
of that, but it depends on either nsWrapperCache (for the global
mapping) or nsISupports (pretty sure on that) for the cross-compartment
mapping. We would have to add extra machinery of one sort of the other
to handle not inheriting from either one.
2) The JS representation needs to be an object. This is probably good
in terms of typesafety (in that we can check whether the object is
actually the thing we were passed), but complicates the other bits. For
example, if this were not a requirement, we could conceivably use a JS
PrivateValue to just directly encode the Encoding* in a value that looks
like a JS Number. This does mean that on JS-to-C++ conversion we'd
effectively reinterpret_cast a double to an Encoding*, so if someone
messed up and passed some random double bad things would happen.
One thing that is not clear to me: do you need support for this on
worker threads, or just mainthread? Because if this is not needed on
workers, one thing we _could_ conceivably do is have some sort of setup
where we define a new type that looks like void* on the C++ side and a
JS object on the JS side, allocate the objects in the privileged junk
scope, give them a recognizable JSClass to typesafety and a PrivateValue
reserved slot for JS-to-C++ mapping, have a xpconnect-wide hashtable for
C++-to-JS mapping. We could either have a finalizer that removes from
the xpconnect-wide hashtable or trace that hashtable and thereby keep
the objects alive forever or whatever; that mostly depends on how you
want them to behave as weakmap keys.
This would be a bit of work, but not too insane, I think.
-Boris
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
