When to start making mojo IPC call without knowing when the service provide is available?

[Tao Jin]

I ported libchrome, libmojo and the mojo service manager from cros project. 

A question maybe about mojo idiom. 

One interesting design of mojo is the remote is considered bound once it is bound to the message pipe in the local process, and the process can start using this remote to make mojo IPC call.  If the receiver end is not yet online/running, the IPC call is cached locally until the receiver end is available. 

Quote from mojo service manager doc "https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/platform2/mojo_service_manager/README.md"

What's the general/best practice here when I want to design/think in the mojo way?

If a process A is connected to mojo service manager and has requested service Foo.  Should A start making Foo service IPC calls, and then patiently wait for the response to trigger the next step work flow on A side?  Does that mean some sort of timer based IPC call is anti-mojo-idiom, because it may have the risk of caching too many pending IPC calls?  Or a more high level question, how should I decide when to start making mojo IPC call if I don't know if there is a remote receiver handling this call. 

Quite a newbie to mojo, and appreciate your insights and sharing !

Tao

[Tao Jin]

Sorry, I didn't quote the mojo service manager design doc correctly in my previous post

With service manager, the services bootstrap is decoupled from the mojo invitation. Callers can always send the mojo receiver instead of waiting for a mojo remote. If the service is not yet registered, the service manager will push the request to a queue and will bind it after the service is available. Users just need to request the service. The mojo remote holds all the method calls until the corresponding pending receiver is bound. And the service manager holds the pending receiver until the service is registered.

[Ken Rockot]

On Tue, Aug 20, 2024 at 6:26 PM Tao Jin <jinta...@gmail.com> wrote:

I ported libchrome, libmojo and the mojo service manager from cros project. 

A question maybe about mojo idiom. 

One interesting design of mojo is the remote is considered bound once it is bound to the message pipe in the local process, and the process can start using this remote to make mojo IPC call.  If the receiver end is not yet online/running, the IPC call is cached locally until the receiver end is available. 

Quote from mojo service manager doc "https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/platform2/mojo_service_manager/README.md"

What's the general/best practice here when I want to design/think in the mojo way?

If a process A is connected to mojo service manager and has requested service Foo.  Should A start making Foo service IPC calls, and then patiently wait for the response to trigger the next step work flow on A side?

In Chrome we always use remotes as soon as it's useful to do so, without regard for whether their receiver is bound yet. Mojo encourages this by design. It's rare for a pending receiver to be held for long, and typically they're routed to the right place and bound ASAP.

 

Does that mean some sort of timer based IPC call is anti-mojo-idiom, because it may have the risk of caching too many pending IPC calls?

Timer-based calls can make sense. Chrome for example often sends display-update signals to processes on a timer which matches the display refresh rate (e.g. 60 Hz). If you're concerned about a service becoming unresponsive and messages piling up, you can always have them reply -- or have some other less frequent message on the same interface, with a reply -- so you can gauge responsiveness and implement back-pressure. We do this for some interfaces only if there's evidence of a problem.

Or a more high level question, how should I decide when to start making mojo IPC call if I don't know if there is a remote receiver handling this call.

You can design your system so that you don't have to think about this in most cases, by not retaining pending receivers when you acquire them. Instead always immediately pass them elsewhere, or bind them, or discard them.

 

Quite a newbie to mojo, and appreciate your insights and sharing ! 

Tao

--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-moj...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/5fbab4b4-c488-4a1e-8399-5afb45779f8bn%40chromium.org.