--
--
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 view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAJ6%3Dx6nXFzqnUnTRiypU%2BZ2kGyRFRzeJzuV1d_ztdAh%2BO9aAdw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAPUDrwfheT3k2Z6YhsdnndBK1Fqt_YYM6WwVrAETp3rGbQWk%2BA%40mail.gmail.com.
As Dale mentions, this is a topic that's come up a number of times before.In the past, one idiom I've seen is to have a main class Foo and a helper class FooIOHelper. Each one stores the task runner to post tasks to (i.e. Foo owns the FooIOHelper and stores a ref to the IO thread task runner, and FooIOHelper holds a back pointer to Foo and stores a ref to the main thread task runner). I'm curious if this is something that would work for the instances you've encountered.
On Tue, Feb 13, 2018 at 1:49 PM, Daniel Cheng <dch...@chromium.org> wrote:As Dale mentions, this is a topic that's come up a number of times before.In the past, one idiom I've seen is to have a main class Foo and a helper class FooIOHelper. Each one stores the task runner to post tasks to (i.e. Foo owns the FooIOHelper and stores a ref to the IO thread task runner, and FooIOHelper holds a back pointer to Foo and stores a ref to the main thread task runner). I'm curious if this is something that would work for the instances you've encountered.It would work for that case I was mentioning as an example (UI to IO thread call with Closure).It does not work for another case I ran into, which is mojo::WrapCallbackWithDropHandler. This is a helper method that guarantees the callback is invoked when doing a Mojo interface call, even if the task is dropped, if the service crashed for example. (useful when you don't own the InterfacePtr and cannot use InterfacePtr::set_connection_error_handler) However that helper makes no guarantees on which thread the task will be run in that case, so BindToCurrentLoop would be pretty handy in that case.
As Dale mentions, this is a topic that's come up a number of times before.In the past, one idiom I've seen is to have a main class Foo and a helper class FooIOHelper. Each one stores the task runner to post tasks to (i.e. Foo owns the FooIOHelper and stores a ref to the IO thread task runner, and FooIOHelper holds a back pointer to Foo and stores a ref to the main thread task runner). I'm curious if this is something that would work for the instances you've encountered.The advantages of this pattern are that the task runner restrictions are delineated by class boundaries and we don't need 2 callback template instantiations to trampoline a callback + its bound arguments back to the correct task runner.However, it does require separate code out into separate classes which can be non-trivial. I'm also a bit unclear on how the proposed base::Promise API would handle cross-sequence promises, e.g. would it work in a similar way to BindToCurrentLoop today?
base::ManualPromiseResolver<void> mpr;
mpr.promise().Then(ui_sequence, FROM_HERE, base::Bind(&NextStep));
OldStyleApiWhichRunsStuffOnTheIoThread(mpr.GetResolveCallback());
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/CAF3XrKoWMB%2B%3D6Q%3DCvuRsE8X6e4qVzADQSf8VVsAcTAZaaCmKLg%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
This looks interesting, and I would guess that with the migration to use sequences, this would lay the inevitable foundation for co-routines.
--
--
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/f890c03c-f2bd-4378-8c96-a578f73f2ae0%40chromium.org.