RevocableInterfacePtr what do do with...

40 views
Skip to first unread message

Dave Tapuska

unread,
Sep 13, 2019, 2:29:01 PM9/13/19
to Mario Sanchez Prada, platform-architecture-dev, Ken Rockot
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

unread,
Sep 16, 2019, 5:07:33 AM9/16/19
to Dave Tapuska, Mario Sanchez Prada, platform-architecture-dev, Ken Rockot
+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

unread,
Sep 17, 2019, 12:10:25 PM9/17/19
to Kentaro Hara, Dave Tapuska, Mario Sanchez Prada, platform-architecture-dev
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

unread,
Sep 17, 2019, 12:11:17 PM9/17/19
to Kentaro Hara, Dave Tapuska, Mario Sanchez Prada, platform-architecture-dev
But I agree that in general Revocable* should go away.

Kentaro Hara

unread,
Sep 17, 2019, 8:32:26 PM9/17/19
to Ken Rockot, Yuta Kitamura, Dave Tapuska, Mario Sanchez Prada, platform-architecture-dev
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

unread,
Sep 18, 2019, 1:12:53 AM9/18/19
to Kentaro Hara, Ken Rockot, Dave Tapuska, Mario Sanchez Prada, platform-architecture-dev
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.)
Reply all
Reply to author
Forward
0 new messages