Connection error handlers for client bindings

[Rouslan Solomakhin]

Does the client binding need an error handler? Example code:

ConnectToRemoteService(mojo::GetProxy(&service_));

service_->set_connection_error_handler(base::Bind(&ClientClass::OnConnectionError, this));

service_->SetClient(client_binding_.CreateInterfacePtrAndBind());

// Is this also necessary?

client_binding_->set_connection_error_handler(base::Bind(&ClientClass::OnConnectionError, this));

[Scott Violet]

A connection error handler is not necessary. More often than not you
want to cleanup when other end goes away, that's when the connection
error handler is used.

-Scott

> --
> 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 post to this group, send email to chromi...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/467c51bd-e88d-46b9-b56d-01113ea5202b%40chromium.org.

[Marijn Kruisselbrink]

Well yes, a connection error handler is not necessary if you're not interested in handling connection errors. But as you say, usually you do want to do something when the connection goes away, so you do need a connection error handler. And more specifically since the Client interface is an entirely separate pipe/connection you should probably have both a connection error handler for the client and service connection, even though it is likely that when one connection unexpectedly dies the other one will die as well.

But maybe this kind of pattern where you connect to a service and then pass a client interface to that service is one situation where it might make a lot of sense to have the client interface be an associated interface, so there is only one pipe for messages in both directions? Or is that not what associated interfaces were designed for?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CAKARY_kJFg973Uy76v%3DNRjUSNy%2BMoAUR%2BmhSgKqbKmHBgUX3yA%40mail.gmail.com.

[Rouslan Solomakhin]

I cannot think of a use case for maintaining two pipes for client-server communication. IMHO, I would suggest the mojo implementation to maintain a single pipe by default. Please correct me if I'm missing something important.

[Scott Violet]

At one point clients were an intrinsic part of mojom. It proved a
built awkward and was removed. Search the mojo-dev threads if you're
curious.

-Scott

[Rouslan Solomakhin]

Reading this:

https://groups.google.com/a/chromium.org/d/msg/mojo-dev/eqsG0aeALLo/Klovi1HJAtsJ

Great to know! Thank you for pointing it out.

[Yuzhu Shen]

The associated interface feature is a "superset" of the deprecated [Client=] feature.

It seems appropriate to me to use it to put service and client interfaces on the same message pipe. Benefits:

- When the master interface / underlying message pipe is closed, all associated interfaces are disconnected. So you don't have to handle cases such as "what if the service pipe is closed and the client pipe isn't"?

- FIFO guarantee:

    service_callback.Run();

  client->DoStuff();

  Assume that |service_callback| is a callback for a call on the service interface; |client| is the corresponding client interface. If the client is an associated interface, it is guaranteed that the callback arrives at the other end prior to the DoStuff() call.

One thing should be noted: associated interfaces living on different threads than the master interface needs an extra thread hop for dispatching received messages. (Usually client/service interfaces are used on the same thread at both sides, in that case it shouldn't be a problem.)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CAMMzaWEwRgedhub7LDSz_H4Lne2AMrZ0sO1qvaRmb%3DUsv0VwTA%40mail.gmail.com.