RevocableInterfacePtr what do do with...

[Dave Tapuska]

Was looking at what was left in blink for mojo conversions. Do we have a plan for attack for the RevocableInterfacePtr?

I wonder if it is really necessary to keep this plumbing. It seems that it is used in

1) Speech Recognition, this already is a ContextLifecycleObserver so it could just close the binding and the receiver in the ContextDestroyed callback.

2) Geolocation is also a lifecycle observer.

3) CacheStorage is a ContextClient but it could be upgraded to a ContextLifecycleObserver.

4) NativeFileSystem, seems to create a bunch of them in their call graphs but they can all get a handle to the ExecutionContext so I believe they could be LifecycleObservers.

rockot@ I'd like your opinion on this. As these RovocableBinding, InterfaceInvalidator etc don't seem to bring a whole lot.

Kentaro any opinions, I presume we should close some of these mojo channels for frozen tabs too... 

dave.

[Kentaro Hara]

+1 to deprecating RevocableInterfacePtr.

The real problem is that Mojo does not have any mechanism to close the binding when (a) an ExecutionContext is closed or (b) an associated Oilpan object becomes unreachable.

RevocableInterfacePtr is a half-baked solution in the sense that it solves only (a). We're sometimes solving (a) with ContextLifecycleObservers. We're solving (b) using hand-written pre-finalizers.

I think we should come up with an abstraction that can solve both (a) and (b) :)

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAHgVhZV5KDJCXkWcv165iWYYkOtZ-byzfsyh_C-EHrGEXAciWg%40mail.gmail.com.

--

Kentaro Hara, Tokyo, Japan

[Ken Rockot]

I recall discussing many months ago the idea that we should just define Blink-only Remote/Receiver implementations within Blink, with GC/context lifetime awareness. I thought someone in TOK was going to work on that but I don't remember who.

[Ken Rockot]

But I agree that in general Revocable* should go away.

[Kentaro Hara]

I recall discussing many months ago the idea that we should just define Blink-only Remote/Receiver implementations within Blink, with GC/context lifetime awareness. I thought someone in TOK was going to work on that but I don't remember who.

+Yuta Kitamura :)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CA%2BapAgEkpWggH47xi3P5eEBL46m1Zn0OTrNYX40zqdjxEBpgew%40mail.gmail.com.

[Yuta Kitamura]

Well yeah I think we really should introduce Blink-specific (or more correctly, renderer-specific) variant of Mojo interfaces. (This was punted because this turned out to be non-urgent for bfcache, but from a general architectural perspective, this would be fairly important.)