Waiting on result of a callback

35 views
Skip to first unread message

baile...@google.com

unread,
Dec 5, 2017, 3:04:14 PM12/5/17
to Chromium-dev
Hi!


I was hoping someone could point me in the right direction. I'm trying to accomplish the following:

BarResult TwoCalls(arg) {
  // callback signature: void MyCallback(result_value, error_code)
  call Foo(arg, callback)
  error_code = WaitOnCallbackAndGetErrorCode(callback)
  if FAILED(error_code) return error_code

  return Bar(arg)
}

I'm wondering if there's some Chromium magic to wait for a callback. The reason we are making this synchronous is because if Foo fails, Bar must not be called, but the caller of TwoCalls should be returned the result of Bar().

Thanks!

Ken Rockot

unread,
Dec 5, 2017, 3:11:06 PM12/5/17
to baile...@google.com, Chromium-dev
You should almost always prefer to make TwoCalls itself asynchronous in this case, especially if this is production code.

Can you please provide more context? If this is for test-only code, it is fairly common to spin a RunLoop while waiting for a condition to be fulfilled.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/86de15de-2a4d-43be-895b-a3cc557633cc%40chromium.org.

baile...@google.com

unread,
Dec 5, 2017, 3:23:39 PM12/5/17
to Chromium-dev, baile...@google.com
Thanks for the reply. Sure- let me add some details. We are working on adding native support for smb filesystems. We have refactored file_system_provider::service to support native providers in addition to extensions (currently supported). The entry point for mounting an SMB filesystem will eventually be a bit of UI with a mount button, that should call SmbService::Mount() [1]. Here is a hacky example from awhile ago calling Service::Mount() from a button press [2] (but now this would be a call to SmbService::Mount(). SmbService::Mount() in turn should first call SmbProvider::Mount() which communicates w/ a Daemon via DBUS. SmbService::Mount() would then call Service::Mount() on success, and return the result of that function.  Here is some more detailed psuedocode:

BaseSmbService::Mount(share_path)
- // void MountCallback(mount_id, error)
- SmbProviderClient.Mount(string share_path, MountCallback callback)
- Wait on the callback
- Check the error, and map and return if failed
- return Service::Mount(...)

Sorry if this is too much detail, but maybe it helps explain our issue better.



On Tuesday, December 5, 2017 at 12:11:06 PM UTC-8, Ken Rockot wrote:
You should almost always prefer to make TwoCalls itself asynchronous in this case, especially if this is production code.

Can you please provide more context? If this is for test-only code, it is fairly common to spin a RunLoop while waiting for a condition to be fulfilled.
On Tue, Dec 5, 2017 at 12:04 PM, baileyberro via Chromium-dev <chromi...@chromium.org> wrote:
Hi!


I was hoping someone could point me in the right direction. I'm trying to accomplish the following:

BarResult TwoCalls(arg) {
  // callback signature: void MyCallback(result_value, error_code)
  call Foo(arg, callback)
  error_code = WaitOnCallbackAndGetErrorCode(callback)
  if FAILED(error_code) return error_code

  return Bar(arg)
}

I'm wondering if there's some Chromium magic to wait for a callback. The reason we are making this synchronous is because if Foo fails, Bar must not be called, but the caller of TwoCalls should be returned the result of Bar().

Thanks!

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

Ken Rockot

unread,
Dec 5, 2017, 3:32:18 PM12/5/17
to baile...@google.com, Chromium-dev
On Tue, Dec 5, 2017 at 12:23 PM, baileyberro via Chromium-dev <chromi...@chromium.org> wrote:
Thanks for the reply. Sure- let me add some details. We are working on adding native support for smb filesystems. We have refactored file_system_provider::service to support native providers in addition to extensions (currently supported). The entry point for mounting an SMB filesystem will eventually be a bit of UI with a mount button, that should call SmbService::Mount() [1]. Here is a hacky example from awhile ago calling Service::Mount() from a button press [2] (but now this would be a call to SmbService::Mount(). SmbService::Mount() in turn should first call SmbProvider::Mount() which communicates w/ a Daemon via DBUS. SmbService::Mount() would then call Service::Mount() on success, and return the result of that function.  Here is some more detailed psuedocode:

BaseSmbService::Mount(share_path)
- // void MountCallback(mount_id, error)
- SmbProviderClient.Mount(string share_path, MountCallback callback)
- Wait on the callback
- Check the error, and map and return if failed
- return Service::Mount(...)

Sorry if this is too much detail, but maybe it helps explain our issue better.

That's all fine, but I still don't understand why you need the "wait on the callback" step. That means blocking a Chrome thread that could otherwise be getting work done while the SMB service is off doing whatever it needs to do. I would strongly encourage you to consider making the Mount API itself asynchronous to eliminate any need for blocking operations.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/1363d613-c483-47d0-ac67-cf48eb984240%40chromium.org.

Alex Clarke

unread,
Dec 5, 2017, 3:42:01 PM12/5/17
to baile...@google.com, Chromium-dev
Would PostTaskAndReply help here?

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/1363d613-c483-47d0-ac67-cf48eb984240%40chromium.org.

Reply all
Reply to author
Forward
0 new messages