Hello,
I'm using mojo to wrap an opaque structure (some platform resource) into a mojo::ScopedHandle which I then later use to pass around mojom interfaces and processes.
In normal scenarios, this handle is held by an existing Chromium object (media::DecoderBuffer) and once I'm consuming this object I can then free my opaque structure inside the mojo::ScopedHandle.
But during error cases, when the object holding ownership of this handle is freed (it's a unique_ptr<>) the Handle is closed and I'm leaking the platform resource referenced as the opaque pointer inside the ScopedHandle.
I would like to know if it's possible for a process/interface (initial producer of the ScopedHandle) to know if at some point it's closed ?
Looking at the documentation it seems there is the mojo::HandleSignalTracker interface but it's only for MessagePipe and DataPipe.
What would be the best way to know when a mojo::ScopedHandle is closed by another process ?
So far the only solutions I found were (1) to send a PendingRemote<> alongside the Handle to free what's inside or (2) Also send a MessagePipe and use the signal API to watch for the "peer closed" event.
But none of those solutions are appealing.
PS: My problem is not with the memory of the opaque structure inside the handle but the platform resource it's referring to
--
Thanks,---Patrice Blin
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%2BrBgJiAEnyV-%3DFE4xcHpPQMhtsNAynyoPpWZEzYFJ%2BRurcCCg%40mail.gmail.com.
On Thu, Apr 22, 2021 at 9:17 AM Patrice Blin <pb...@wyplay.com> wrote:Hello,
I'm using mojo to wrap an opaque structure (some platform resource) into a mojo::ScopedHandle which I then later use to pass around mojom interfaces and processes.
In normal scenarios, this handle is held by an existing Chromium object (media::DecoderBuffer) and once I'm consuming this object I can then free my opaque structure inside the mojo::ScopedHandle.It's not clear to me what you mean by this arrangement. How are you wrapping an opaque structure? You say a platform resource, so do you mean you're using mojo::WrapPlatformHandle? If so, the lifetime of the platform handle is owned by the MojoHandle, so when the MojoHandle is closed, the platform handle is closed. But I assume that can't be what you mean or you wouldn't have this problem.
But during error cases, when the object holding ownership of this handle is freed (it's a unique_ptr<>) the Handle is closed and I'm leaking the platform resource referenced as the opaque pointer inside the ScopedHandle.
I would like to know if it's possible for a process/interface (initial producer of the ScopedHandle) to know if at some point it's closed ?No, not possible in the general case.
Looking at the documentation it seems there is the mojo::HandleSignalTracker interface but it's only for MessagePipe and DataPipe.
What would be the best way to know when a mojo::ScopedHandle is closed by another process ?
So far the only solutions I found were (1) to send a PendingRemote<> alongside the Handle to free what's inside or (2) Also send a MessagePipe and use the signal API to watch for the "peer closed" event.
But none of those solutions are appealing.If you want to use Mojo to track the lifetime of something in another process, this is in fact the nicest way to do it. We used to have a helper in //mojo/public for exactly this purpose -- it internally used a MessagePipe and a HandleSignalTracker and hid the details -- but it appears to be gone now.
On Mon, 26 Apr 2021 at 19:13, Ken Rockot <roc...@google.com> wrote:On Thu, Apr 22, 2021 at 9:17 AM Patrice Blin <pb...@wyplay.com> wrote:Hello,
I'm using mojo to wrap an opaque structure (some platform resource) into a mojo::ScopedHandle which I then later use to pass around mojom interfaces and processes.
In normal scenarios, this handle is held by an existing Chromium object (media::DecoderBuffer) and once I'm consuming this object I can then free my opaque structure inside the mojo::ScopedHandle.It's not clear to me what you mean by this arrangement. How are you wrapping an opaque structure? You say a platform resource, so do you mean you're using mojo::WrapPlatformHandle? If so, the lifetime of the platform handle is owned by the MojoHandle, so when the MojoHandle is closed, the platform handle is closed. But I assume that can't be what you mean or you wouldn't have this problem.As you guessed I'm not using mojo::WrapPlatformHandle. I'm literally wrapping a structure.I'm using the C api MojoCreateSharedBuffer() and MojoMapBuffer() to create a MojoHandle then create a mojo::Handle with it.
But during error cases, when the object holding ownership of this handle is freed (it's a unique_ptr<>) the Handle is closed and I'm leaking the platform resource referenced as the opaque pointer inside the ScopedHandle.
I would like to know if it's possible for a process/interface (initial producer of the ScopedHandle) to know if at some point it's closed ?No, not possible in the general case.
Looking at the documentation it seems there is the mojo::HandleSignalTracker interface but it's only for MessagePipe and DataPipe.
What would be the best way to know when a mojo::ScopedHandle is closed by another process ?
So far the only solutions I found were (1) to send a PendingRemote<> alongside the Handle to free what's inside or (2) Also send a MessagePipe and use the signal API to watch for the "peer closed" event.
But none of those solutions are appealing.If you want to use Mojo to track the lifetime of something in another process, this is in fact the nicest way to do it. We used to have a helper in //mojo/public for exactly this purpose -- it internally used a MessagePipe and a HandleSignalTracker and hid the details -- but it appears to be gone now.Maybe you are thinking of mojo::SimpleWatcher ?
I will try my hand with MessagePipe then, thanks for the feedback.
--
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%2BrBgJggRddoU3wd3oEK_mnHkbU8nd3j_B9NZ02t7BA7vrSKpA%40mail.gmail.com.
Hi,I'll answer my own question there... switching to mojo::SimpleWatcher instead of mojo::HandleSignalTracker seems to do the trick (anyway it doesn't seem like necessary to have HandleSignalTracker's more complex high/low watcher mechanism since I only need to watch a single peer disconnected event that only occurs one for each instance)
I'm just curious about why mojo::HandleSignalTracker is not supported with ipcz if you care to explain that ;)