Exposing ContextLifecycleNotifier via MojoBindingContext

[Tal Pressman]

Hi all,

Following up on the "per-frame interfaces in platform" thread, renderer/platform now has the concept of MojoBindingContext that includes getters for the per-context BIB and task runners. As discussed in the other thread, it seems like it would make sense to also expose ContextLifecycleNotifier, as it is required by all HeapMojo interfaces.

This can be done in a number of ways:

• Add a `GetContextLifecycleNotifier` method to MojoBindingContext, that is implemented by ExecutionContext as `return this;`.
• Make MojoBindingContext inherit from ContextLifecycleNotifier.
• Merge MojoBindingContext and ContextLifecycleNotifier into a single interface.
• (Any other suggestions?)

Regardless of which we choose, it seems like after the change we would be able to replace/overload the different Bind methods with ones that only take a MojoBindingContext and extract the needed information from it.

My preference (as someone who doesn't really like inheritance) is the first option, but I'm curious to hear what everyone else's opinions on this are.

Tal

[Kouhei Ueno]

On Mon, Dec 14, 2020 at 10:51 AM 'Tal Pressman' via platform-architecture-dev <platform-arc...@chromium.org> wrote:

Hi all,

Following up on the "per-frame interfaces in platform" thread, renderer/platform now has the concept of MojoBindingContext that includes getters for the per-context BIB and task runners. As discussed in the other thread, it seems like it would make sense to also expose ContextLifecycleNotifier, as it is required by all HeapMojo interfaces.

This can be done in a number of ways:

• Add a `GetContextLifecycleNotifier` method to MojoBindingContext, that is implemented by ExecutionContext as `return this;`.
• Make MojoBindingContext inherit from ContextLifecycleNotifier.

I'm personally a fan of this option: MBC inherit from ContextLifecycleNotifier

 

• Merge MojoBindingContext and ContextLifecycleNotifier into a single interface.

I'd like to avoid this for now since I expect some callers to only need the ContextLifecycleNotifier part.

 

• (Any other suggestions?)

Regardless of which we choose, it seems like after the change we would be able to replace/overload the different Bind methods with ones that only take a MojoBindingContext and extract the needed information from it.

My preference (as someone who doesn't really like inheritance) is the first option, but I'm curious to hear what everyone else's opinions on this are.

Tal

--
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/1266123f-dd44-4e1b-bb92-c4eba5a346adn%40chromium.org.

--

kouhei

[Tal Pressman]

I'd like to avoid this for now since I expect some callers to only need the ContextLifecycleNotifier part.

AFAIK, ContextLifecycleNotifier is currently only used for HeapMojo, where we also pass in the task runner. Is that not the case? 

[Kouhei Ueno]

On Mon, Dec 14, 2020 at 11:00 AM Tal Pressman <ta...@google.com> wrote:

I'd like to avoid this for now since I expect some callers to only need the ContextLifecycleNotifier part.

AFAIK, ContextLifecycleNotifier is currently only used for HeapMojo, where we also pass in the task runner. Is that not the case? 

I see, then I'm good with merging as well.

 

On Mon, Dec 14, 2020 at 10:58 AM Kouhei Ueno <kou...@google.com> wrote:

On Mon, Dec 14, 2020 at 10:51 AM 'Tal Pressman' via platform-architecture-dev <platform-arc...@chromium.org> wrote:

Hi all,

Following up on the "per-frame interfaces in platform" thread, renderer/platform now has the concept of MojoBindingContext that includes getters for the per-context BIB and task runners. As discussed in the other thread, it seems like it would make sense to also expose ContextLifecycleNotifier, as it is required by all HeapMojo interfaces.

This can be done in a number of ways:

• Add a `GetContextLifecycleNotifier` method to MojoBindingContext, that is implemented by ExecutionContext as `return this;`.
• Make MojoBindingContext inherit from ContextLifecycleNotifier.

I'm personally a fan of this option: MBC inherit from ContextLifecycleNotifier

 

• Merge MojoBindingContext and ContextLifecycleNotifier into a single interface.

I'd like to avoid this for now since I expect some callers to only need the ContextLifecycleNotifier part.

 

• (Any other suggestions?)

Regardless of which we choose, it seems like after the change we would be able to replace/overload the different Bind methods with ones that only take a MojoBindingContext and extract the needed information from it.

My preference (as someone who doesn't really like inheritance) is the first option, but I'm curious to hear what everyone else's opinions on this are.

Tal

--
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/1266123f-dd44-4e1b-bb92-c4eba5a346adn%40chromium.org.

--

kouhei

--

kouhei

[Kentaro Hara]

I'd prefer merging.

I also prefer giving it a more generic name than MojoBindingContext but we can revisit it when we start using it in more places.

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

--

Kentaro Hara, Tokyo

[Tal Pressman]

Hi all,

The CL to merge ContextLifecycleNotifier into MojoBindingContext is up for review at http://crrev.com/c/2596279.

Please let me know what you think.

Tal

[Tal Pressman]

Hi again,

haraken@ commented on the CL above that it might be time to rename MojoBindingContext to something more generic and suggested SchedulingContext. What does everyone else think?

(Note: The rename might be done in a followup CL or as part of this CL, depending on how long it takes to decide on a name.)

Thanks,

Tal

[Kouhei Ueno]

I have a slight preference for using MojoBindingContext for now, since that's the only use case we have for now. (We can rename it later anytime once it actually gets "generic" usage). However I'm fine with SchedulingContext if there's a strong interest.

--

kouhei