About mojo remote disconnect handler

201 views
Skip to first unread message

Chung-sheng Wu

unread,
Dec 8, 2021, 10:26:13 PM12/8/21
to chromium-mojo, Chrome OS Telemetry/Diagnostics/Manageability Taipei Eng
Hi mojo team,

I found that the disconnect handler won't be set if the interface is not connected. cs. I'm curious that if there is a chance that the connected state change between we check the interface is connected and the disconnect handler is dropped by set_disconnect_handler. That is,

```
if (remote.is_connected()) {
  // <- remote is disconnected here
  remote.set_disconnect_handler(...);
}
```

Also, it is hard to know if the interface is disconnected or has not yet been connected. For the later case, can the |set_disconnect_handler| keep the handler instead of dropping it?

Thanks
Chungsheng

Chung-sheng Wu

unread,
Dec 8, 2021, 10:43:33 PM12/8/21
to chromium-mojo, Chrome OS Telemetry/Diagnostics/Manageability Taipei Eng
Add some clarification.

As I know, if we pass a pending_receiver to another process, the remote will remain "is_connected == false" until the pending_receiver is bound to a receiver in another process.
The remote could be used before another side is bound. However, the disconnect handler will be dropped by |set_disconnect_handler|, and |reset_on_disconnect| will reset the interface. Are these intended?

How to correctly handle the disconnection before the interface is connected?

Thanks

Chung-sheng Wu <chung...@google.com> 於 2021年12月9日 週四 上午11:25寫道:

Jeremy Roman

unread,
Dec 9, 2021, 12:04:12 AM12/9/21
to Chung-sheng Wu, chromium-mojo, Chrome OS Telemetry/Diagnostics/Manageability Taipei Eng
I believe the disconnection will be posted to the remote's task runner and so this cannot happen -- either is_connected will be false, or the disconnect handler will be called. Assuming, that is, that this code is running on the same sequence as the remote.

--
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/CA%2Bzq0vBNLg6TVYjrrj%2BsX62P4KboOWy0ja-_qfC3PvVxmfMHYg%40mail.gmail.com.

Chung-sheng Wu

unread,
Dec 9, 2021, 12:37:36 AM12/9/21
to jbr...@chromium.org, chromium-mojo, Chrome OS Telemetry/Diagnostics/Manageability Taipei Eng
Thanks.
I found that I'm more curious on the second question I asked. That is, how to correctly handle the disconnection before the interface is connected?

Assuming we have:
```
interface FooInterface {
  GetBar(pending_receiver<BarInterface> receiver);
  GetBarWithCallback(pending_receiver<BarInterface> receiver) => ();
}
```

Then:
```
foo_remote->GetBar(bar_remote.CreateNewPipeAndPassReceiver());
bar_remote->set_disconnect_handler(...); // <- This won't work because bar_remote has not yet been connected ?

// Insteadly, we need to do this.
foo_remote->GetBarWithCallback(bar_remote.CreateNewPipeAndPassReceiver(), base::BindOnce(... set disconnect handler in callback ...));
```

Is my understanding correct?

Jeremy Roman <jbr...@chromium.org> 於 2021年12月9日 週四 下午1:04寫道:

Chung-sheng Wu

unread,
Dec 9, 2021, 1:26:07 AM12/9/21
to jbr...@chromium.org, chromium-mojo, Chrome OS Telemetry/Diagnostics/Manageability Taipei Eng
Assuming, that is, that this code is running on the same sequence as the remote.
I guess the remote is running on the mojo IO thread. In chromium, do we usually run on the mojo IO thread? If not, what is the best practice of doing that?

Chung-sheng Wu <chung...@google.com> 於 2021年12月9日 週四 下午1:36寫道:

Chung-sheng Wu

unread,
Dec 9, 2021, 2:16:05 AM12/9/21
to jbr...@chromium.org, chromium-mojo, Chrome OS Telemetry/Diagnostics/Manageability Taipei Eng
foo_remote->GetBar(bar_remote.CreateNewPipeAndPassReceiver());
bar_remote->set_disconnect_handler(...); // <- This won't work because bar_remote has not yet been connected ?
I found that |bar_remote| will be connected after passing the pending_receiver to |foo_remote->GetBar|. So this won't happen.

Chung-sheng Wu <chung...@google.com> 於 2021年12月9日 週四 下午2:25寫道:

Daniel Cheng

unread,
Dec 9, 2021, 3:09:59 AM12/9/21
to Chung-sheng Wu, jbr...@chromium.org, chromium-mojo, Chrome OS Telemetry/Diagnostics/Manageability Taipei Eng
To clarify, a mojo::Remote is considered connected as soon it is bound (e.g. with BindNewPipeAndPassReceiver), *even if* the pending_receiver hasn't been sent anywhere yet, e.g.:

  mojo::Remote<mojom::SomeInterface> new_remote;
  mojo::PendingReceiver<mojom::SomeInterface> pending_receiver =
      new_remote.BindNewPipeAndPassReceiver();
  // always true
  DCHECK(new_remote.is_connected());

Even if pending_receiver is goes out of scope and is never bound, is_connected() will not synchronously become false, e.g. if the snippet above were followed by:

  pending_receiver.reset();
  // Still true, the mojo::Remote is notified asynchronously when the other end of
  // the pipe is closed.
  DCHECK(new_remote.is_connected());

Daniel

Reply all
Reply to author
Forward
0 new messages