Stopping components using fuchsia.component.Realm

[Xyan Bhatnagar]

Hey folks,

Is it reasonable for a parent component to use the fuchsia.component.Realm protocol to stop a child component instance?

I'm imagining this as a new method `StopChild` which accepts a ChildRef and blocks until the child component has stopped. It can even return the exit code it got from the program.

Thoughts?

- Xyan

[Justin Mattson]

This seems like it would make an interesting shift in our stance of "everything runs for a reason". This statement is specific, but more generally I think we have a stance of "everything is in a given state for a reason". The "reason" we've been trying to avoid is "because another component said so".

So far we've had ways to start a child directly, but I am secretly (oops, no longer a secret) hopeful we could find a way to deprecate these. For example, if we had the necessary APIs to define a dynamic child and its routing to the framework then maybe it would be unnecessary to start the component directly.

Maybe we can't pull this off or maybe we can't pull it off now, but if we add a StopChild API we should try to understand whether this is tech debt.

Cheers,

Justin

--
All posts must follow the Fuchsia Code of Conduct https://fuchsia.dev/fuchsia-src/CODE_OF_CONDUCT or may be removed.
---
You received this message because you are subscribed to the Google Groups "component-framework-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to component-framewo...@fuchsia.dev.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CAHacFysUC__5He42xV5SubxSsUxBSSOCwT0CA%2Bk84%3DmniAZhDA%40mail.gmail.com.

[Suraj Malhotra]

Starting a child via dependencies is a non-starter for drivers. Until enumeration has occurred, you don't really understand what components you need to instantiate to make those services available. It needs to be done eagerly. The best you could do is defer device enumeration until someone tries using devfs or services exported by the driver collection. We've talked through this a few times in the DF/CF sync in the past.

As far as needing the ability to control a child component from a parent, we will always need the ability to stop a component due to an event like the usb device being unplugged. I think we manage with the existing API just fine (closing the ComponentController channel seems to work as we don't need to know when it's completed), but removing our ability to do this would be problematic.

To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CA%2BX8dX8%2BvgcSMYK13VzUFcBbTgJ2OE7jT6%3DE%2BrTxVXXmWOyfNQ%40mail.gmail.com.

[Gabe Schine]

Xyan, are you asking specifically about a StopChild() for statically defined children?

We will not remove the ability for a parent to effectively controls a child's lifecycle if it opts to do so.

To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CAFFy6-AD5XXJWW%3Dt9JqNnyuRxgOj8PGZiP4EoSmEiuA%3D-8bpBA%40mail.gmail.com.

--

Gabe Schine

Software Engineer / Manager

🔵 Blue Dot Ally

go/thatguy-readme

go/where-is-thatguy

[Xyan Bhatnagar]

On Mon, Mar 14, 2022 at 3:42 PM Gabe Schine <tha...@google.com> wrote:

Xyan, are you asking specifically about a StopChild() for statically defined children?

For static and dynamic children. The ability for a parent to stop a child using a public API came up recently and it seems like a reasonable request. Parents already have a good amount of control over their children via the Realm protocol.

[Gabe Schine]

Ack.

Maybe we can move this discussion to a feature request bug?

[Dave Smith]

Admittedly, the request came from me so I just filed fxbug.dev/95569

Dave Smith | Developer Relations | smit...@google.com | @devunwired

To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CACNy_LSpwnBy_4K34d6rvNxVosFBM3%3DKr0QmDt9%2BHUNvrw8JDg%40mail.gmail.com.

[Yegor Pomortsev]

Please also see fxbug.dev/94153 [Component Feedback]: Improve consistency of lifecycle operations on child components

To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CAHDnuhsWKzcgLQCvNOoaHESm2cfSDqvTy0ufXCtKg6zbCjqp7g%40mail.gmail.com.

[Dave Smith]

I like yours better, duped :)

Dave Smith | Developer Relations | smit...@google.com | @devunwired

[Justin Mattson]

To be clear my secret hope is that we can find a model that serves all clients well and avoids explicit lifecycle control of children. It is not my secret hope to foist this model on component authors by force.

I think we manage with the existing API just fine (closing the ComponentController channel seems to work as we don't need to know when it's completed), but removing our ability to do this would be problematic.

Being in control of the runner here affords DF some control that many authors don't have since that channel is part of the contract between Runners and the component manager. 

[Gary Bressler]

Were there concrete use case(s) motivating the request for StopChild? If so, could you mention them on the bug?

With more context, it'll be easier to evaluate what kind of API is needed to solve the requirements. If the client wants guarantees that the entire sub-realm will be stopped, the existing Stop API from LifecycleController might not be sufficient. Even if the stop is recursive, one of the components in the realm could reanimate if something binds to it. 

To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CA%2BX8dX-f9Yt7vzV_vHY1pFNrCvNd3DeKoSo-ygyD%3Dx7R_H1U4Q%40mail.gmail.com.