Run() on callback destruction if it never ran

[Xiaohan Wang (王消寒)]

Hello,

There are cases where a caller always expect a callback (OnceCallback) to run to proceed to the next step. However, the callback might be dropped somewhere and never ran. For example, a callback is stored in a RunLoop and got dropped during tear down. 

One more realistic example is when making a mojo call like this:

void Foo::Bar(ResultCB result_cb) {
  foo_ptr_->Bar(base::Bind(&Foo::OnResult, weak_ptr_, base::Passed(&result_cb)));
}

If a connection error happened, the callback will be dropped without ever running (correct me if I am wrong).

To work around this issue, currently I have to store a callback such that when connection error happens, we can run all stored callbacks:

void Foo::Bar(ResultCB result_cb) {

  result_cb_ = std::move(result_cb);
  foo_ptr_->Bar(base::Bind(&Foo::OnResult, weak_ptr_));
}

void Foo::OnConnectonError() {

  if (result_cb_)

    std::move(result_cb_).Run(false);
}

However, this makes code ugly and harder to maintain.

I wonder whether it makes sense to introduce a RunOnDestruction() wrapper such that when a callback is destructed without ever running, the callback will be run with some default parameter automatically. So the above code will become:

void Foo::Bar(ResultCB result_cb) {
  foo_ptr_->Bar(RunOnDestruction(

      base::Bind(&Foo::OnResult, weak_ptr_, base::Passed(&result_cb)),

      false  // default parameter when running callback during destruction

      ));
}

I created a prototype CL to show the implementation with some tests. I also tried this with mojo bindings to demo that this does solve the mojo example above. The CL is for POC only and is not ready for full review.

So, do all of these make sense? If we all agree on the problem and solution, I can polish/update my CL for review.

Best,

Xiaohan

[dan...@chromium.org]

Storing default values can be problematic, as perhaps they are not known at the time of Callback creation but would be know at the time of destruction. In graphics code we solved a similar problem with SingleReleaseCallback. It DCHECKs that the callback was run before being destroyed. This makes it easier to maintain the assertion, also the type being distinct from just a base::{Once}Calback make this possible too. Here's an example of calling the SingleReleaseCallback with default values before destroying it in cases where other code can't guarantee it.

 

Best,

Xiaohan

--
--
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/CAF1j9YMQNiiPD0J51Grkbr%2B5tUUmaL-ZoUY617VVqLC%3Dz4foyQ%40mail.gmail.com.

[Xiaohan Wang (王消寒)]

Agreed that this won't solve all problems. But in a lot of cases we do know what default values to use. Give that this will be mostly useful for error handling, specifying values to use when error happens shouldn't be hard.

In graphics code we solved a similar problem with SingleReleaseCallback. It DCHECKs that the callback was run before being destroyed.

Acknowledged!

 

This makes it easier to maintain the assertion, also the type being distinct from just a base::{Once}Calback make this possible too. Here's an example of calling the SingleReleaseCallback with default values before destroying it in cases where other code can't guarantee it.

It seems this is similar to the example above where I have to store the original callback as a member variable, which will be run during failure or tear down, with the benefit of a DCHECK to catch programming error. 

RunOnDestruction is proposed so that we don't have to use this workaround, which is more complicated IMHO.

[Bernhard Bauer]

I think ScopedClosureRunner does that?

Bernhard.

 

 

Best,

Xiaohan

--
--
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/CAF1j9YMQNiiPD0J51Grkbr%2B5tUUmaL-ZoUY617VVqLC%3Dz4foyQ%40mail.gmail.com.

--
--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAF1j9YNMjChYUnYPwNqadhMhFSSOXFRNbKUT49UgbqZrNmhLTw%40mail.gmail.com.

[Xiaohan Wang (王消寒)]

(I thought I replied to the thread but apparently I didn't. Re-reply to the thread.)

I need this to simplify some implementation in media/. If there's no general interest, I can implement this in media/ first.

ScopedClosureRunner only works with base::Closure, and as such there's no way to run the callback with different parameters, e.g. to indicate failure.

Bernhard.

 

 

Best,

Xiaohan

--
--
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/CAF1j9YMQNiiPD0J51Grkbr%2B5tUUmaL-ZoUY617VVqLC%3Dz4foyQ%40mail.gmail.com.

--
--
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.

[David Roger]

You could always use an indirection: pass a pointer to your argument instead of the argument directly, and then you can update its value without worrying about affecting the closure itself.

 

Bernhard.

 

 

Best,

Xiaohan

--
--
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/CAF1j9YMQNiiPD0J51Grkbr%2B5tUUmaL-ZoUY617VVqLC%3Dz4foyQ%40mail.gmail.com.

--
--
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.

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

--

--
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/CAF1j9YNJP%2BQAVZC36R6PokFKVGQqEzZSa1jtph9-p2dXVFR-hA%40mail.gmail.com.

[Jan van Oort]

A bit late, but yes - this makes sense. I've had similar cases in my own code. Solution: use a shutdown hook. Which is essentially what you're doing here. 

--
--
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.

[Xiaohan Wang (王消寒)]

For the record, the CL to add a media::ScopedCallbackRunner to do what's proposed in this thread is landed in https://chromium-review.googlesource.com/c/562751/

[leon...@intel.com]

Hi,

I was told by Reilly about this media::ScopedCallbackRunner impl, it's just what we wanted to use when transferring //extensions/browser/api/{hid, serial}/ from calling Hid/Serial raw APIs to consuming some mojo interfaces which embed corresponding raw APIs. To avoid extensions hanging, we NEED to ensure mojo call response callback to be fired in whatever cases, even if mojo pipe disconnected unexpectedly.

I do think this is generally useful for mojofication/servicification work. So could we move this media::ScopedCallbackRunner into a better place so it can be shared across wider range? Is //base a proper place? Or other suggestions? Thanks.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Dale Curtis]

No objection from media OWNERs.

- dale

--
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-mojo+unsubscribe@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/040eb23c-6d38-48a6-a024-539b9651c73f%40chromium.org.

[Ken Rockot]

//base owners should weigh in here.

At the very least think it might be a good idea to update ScopedCallbackRunner to support sequence affinity if it's going to be made generally available from base.

Especially with mojo bindings consumers as a common use case, typically the bound callback has to do work with sequence affinity, but the callback may be passed around across arbitrary sequence boundaries and destroyed at any time if dropped along the way. It would be nice if there were a simple way to express that you want the default callback execution to happen on the sequence which created the ScopedCallbackRunner. Maybe we'd even want to make this behavior opt-out rather than opt-in?

[Wez]

FWIW kmarshall@ drafted a sequence-affine callback helper for //base, but there were concerns about it making the sequence/thread-hopping less visible to calling code (see https://chromium-review.googlesource.com/c/531916/).

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CA%2BapAgGVtrzsnUkgMd1mcYZSWC5_THV-kweZiB_usnd0OVZtsg%40mail.gmail.com.

[Taiju Tsuiki]

I'd +1 to moving it to //base.

There are at least three callback wrappers for sequence-affinity [1,2,3], and at least 5 wrappers for destruction hook [4,5,6,7,8]. That indicates strong needs for them. However, there seem common pitfalls for them. E.g., destruction threads, never-ran case handling, FROM_HERE propagation, misused Perfect Forwarding, argument wrapper handling.

So, rather than maintaining them independently, it looks nice to me to consolidate these effort.

[1]: BindToCurrentLoop

[2]: RelayCallbackToTaskRunner

[3]: AttachToTaskRunner

[4]: SingleReleaseCallback

[5]: SingleReleaseCallbackImpl

[6]: ScopedCallbackRunner

[7]: ScopedClosureRunner

[8]: ScopedResultCallback (Replaced with ScopedCallbackRunner recently).

2017年8月11日(金) 2:11 Wez <w...@chromium.org>:

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/040eb23c-6d38-48a6-a024-539b9651c73f%40chromium.org.

--
--

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/CA%2BapAgGVtrzsnUkgMd1mcYZSWC5_THV-kweZiB_usnd0OVZtsg%40mail.gmail.com.

--
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/CALekkJcMFaUQz%3DFnM9%2BP0RSOJFN0oEyqNoAZqDd5XK43Z%3DoTSA%40mail.gmail.com.

[Joe Mason]

Another +1 to moving it to base. This would be quite useful for an out-of-tree project I'm working on that uses chromium's base/ for utility classes and mojo/ for IPC.

I don't think sequence-affinity should hold up the move. The most common way to use this is to wrap a Mojo result callback, which already has to be executed on the IPC sequence. So adding ScopedCallbackRunner doesn't change the sequence-affinity of the callback, and whatever method the calling code is using to ensure the callback runs on the right sequence will still apply to the wrapped callback.

Finding a good callback wrapper for sequence-affinity solves a different problem and should be done on a different layer.

I'm not sure about the name, though - it's tempting to treat this as an analogue of ScopedClosureRunner, but they have quite different semantics.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-mojo+unsubscribe@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/040eb23c-6d38-48a6-a024-539b9651c73f%40chromium.org.

--
--

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/CA%2BapAgGVtrzsnUkgMd1mcYZSWC5_THV-kweZiB_usnd0OVZtsg%40mail.gmail.com.

--
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-mojo+unsubscribe@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/CALekkJcMFaUQz%3DFnM9%2BP0RSOJFN0oEyqNoAZqDd5XK43Z%3DoTSA%40mail.gmail.com.

--

--
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/CAFK_eqT%3DVPFgtzMctnSQOivuL0F3Y8wTspsDaDv9HCSzFo2aMA%40mail.gmail.com.

[Daniel Cheng]

On Wed, Aug 16, 2017 at 10:19 AM Joe Mason <joenot...@chromium.org> wrote:

Another +1 to moving it to base. This would be quite useful for an out-of-tree project I'm working on that uses chromium's base/ for utility classes and mojo/ for IPC.

I don't think sequence-affinity should hold up the move. The most common way to use this is to wrap a Mojo result callback, which already has to be executed on the IPC sequence. So adding ScopedCallbackRunner doesn't change the sequence-affinity of the callback, and whatever method the calling code is using to ensure the callback runs on the right sequence will still apply to the wrapped callback.

Finding a good callback wrapper for sequence-affinity solves a different problem and should be done on a different layer.

I'm not sure about the name, though - it's tempting to treat this as an analogue of ScopedClosureRunner, but they have quite different semantics.

I'm not opposed to ScopedCallbackRunner. This seems fine.

However, I'd prefer leaving sequence affinity out of it. I've been opposed to moving BindToCurrentLoop into //base, since it captures (often non-obvious) global state into a callback. Building a general way to encode sequence affinity into callbacks is problematic as well: it's been my experience in code reviews that this sort of thing can lead to confusing code. Where possible, separating the code into sequence-affine objects and then posting callbacks between them is usually easier to understand (and doesn't incur the cost of creating a trampoline callback just to jump to another task runner).

The concerns around Mojo are interesting; how often do we expect to use ScopedCallbackRunner in conjunction with Mojo? Given that Mojo already does the right thing for interface method dispatching, how hard would it be for Mojo to dispatch to the corresponding task runner when disposing these objects?

Daniel

 

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/040eb23c-6d38-48a6-a024-539b9651c73f%40chromium.org.

--
--

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/CA%2BapAgGVtrzsnUkgMd1mcYZSWC5_THV-kweZiB_usnd0OVZtsg%40mail.gmail.com.

--
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/CALekkJcMFaUQz%3DFnM9%2BP0RSOJFN0oEyqNoAZqDd5XK43Z%3DoTSA%40mail.gmail.com.

--
--
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/CAFK_eqT%3DVPFgtzMctnSQOivuL0F3Y8wTspsDaDv9HCSzFo2aMA%40mail.gmail.com.

--
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/CAH%3DT95T5vd_9%2B-m6AkCCqYFK%2BjGXqZg_G1TBbJfKqdd2tKEOZA%40mail.gmail.com.

[Ken Rockot]

On Wed, Aug 16, 2017 at 2:18 PM, Daniel Cheng <dch...@chromium.org> wrote:

On Wed, Aug 16, 2017 at 10:19 AM Joe Mason <joenot...@chromium.org> wrote:

Another +1 to moving it to base. This would be quite useful for an out-of-tree project I'm working on that uses chromium's base/ for utility classes and mojo/ for IPC.

I don't think sequence-affinity should hold up the move. The most common way to use this is to wrap a Mojo result callback, which already has to be executed on the IPC sequence. So adding ScopedCallbackRunner doesn't change the sequence-affinity of the callback, and whatever method the calling code is using to ensure the callback runs on the right sequence will still apply to the wrapped callback.

Finding a good callback wrapper for sequence-affinity solves a different problem and should be done on a different layer.

I'm not sure about the name, though - it's tempting to treat this as an analogue of ScopedClosureRunner, but they have quite different semantics.

I'm not opposed to ScopedCallbackRunner. This seems fine.

However, I'd prefer leaving sequence affinity out of it. I've been opposed to moving BindToCurrentLoop into //base, since it captures (often non-obvious) global state into a callback. Building a general way to encode sequence affinity into callbacks is problematic as well: it's been my experience in code reviews that this sort of thing can lead to confusing code. Where possible, separating the code into sequence-affine objects and then posting callbacks between them is usually easier to understand (and doesn't incur the cost of creating a trampoline callback just to jump to another task runner).

The concerns around Mojo are interesting; how often do we expect to use ScopedCallbackRunner in conjunction with Mojo? Given that Mojo already does the right thing for interface method dispatching, how hard would it be for Mojo to dispatch to the corresponding task runner when disposing these objects?

Solving the Mojo case would essentially mean making response callbacks runnable from any sequence, doing an implicit PostTask if called from off-sequence. Perhaps that's not a bad idea.

Daniel

 

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-mojo+unsubscribe@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/040eb23c-6d38-48a6-a024-539b9651c73f%40chromium.org.

--
--

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/CA%2BapAgGVtrzsnUkgMd1mcYZSWC5_THV-kweZiB_usnd0OVZtsg%40mail.gmail.com.

--
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-mojo+unsubscribe@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/CALekkJcMFaUQz%3DFnM9%2BP0RSOJFN0oEyqNoAZqDd5XK43Z%3DoTSA%40mail.gmail.com.

--
--
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/CAFK_eqT%3DVPFgtzMctnSQOivuL0F3Y8wTspsDaDv9HCSzFo2aMA%40mail.gmail.com.

--
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-mojo+unsubscribe@chromium.org.

[Xiaohan Wang (王消寒)]

Just back from vacation :)

Also +1 for moving this to base, it definitely made a lot of my code cleaner and can be generically useful.

And I agree with Daniel about leaving sequence affinity out of it, for the same reason BindToCurrentLoop is not in base/. As a media owner, I also see how BindToCurrentLoop can be abused given the simplicity of the API hiding the implicit non-trivial cost of the implementation.

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

[Joe Mason]

Can we bikeshed a name change for this? I do think that the similarity to ScopedClosureRunner is confusing when the semantics are quite different. (ScopedCallbackRunner is a callback itself and can be invoked - which makes "Runner" a misleading name - while ScopedClosureRunner is a container object.)

How about CallbackWithDefaultValue? No, it's not clear when the default is used.

I've got it - CallbackWithFallback!

[Daniel Cheng]

On Thu, Nov 30, 2017 at 10:06 PM <joenot...@google.com> wrote:

I see there's now two copies of this class checked into chromium in (//extensions/utility/ and //media/base/), plus I have another copy of it in an internal project that uses //base and //mojo. So if there are no objections, I'll go ahead and make a patch to move it into //base.

There was some more discussion off the mailing list in https://chromium-review.googlesource.com/c/chromium/src/+/724763, which tried to do just that: in the end, both danakj@ and I were quite hesitant about adding anything like this. In fact, I'd strongly prefer to see us wholly remove the ScopedCallbackRunner from the codebase.

Daniel

 

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/040eb23c-6d38-48a6-a024-539b9651c73f%40chromium.org.

--
--

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/CA%2BapAgGVtrzsnUkgMd1mcYZSWC5_THV-kweZiB_usnd0OVZtsg%40mail.gmail.com.

--
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/CALekkJcMFaUQz%3DFnM9%2BP0RSOJFN0oEyqNoAZqDd5XK43Z%3DoTSA%40mail.gmail.com.

--
--

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/CAFK_eqT%3DVPFgtzMctnSQOivuL0F3Y8wTspsDaDv9HCSzFo2aMA%40mail.gmail.com.

--
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/CAH%3DT95T5vd_9%2B-m6AkCCqYFK%2BjGXqZg_G1TBbJfKqdd2tKEOZA%40mail.gmail.com.

--
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.

[Reilly Grant]

There are two problems in Mojo this is trying to solve:

1) Prevent a method from exiting without invoking a callback. This is useful when implementing Mojo methods since they return void and so there is no way to for the compiler to enforce a return value on all exit paths.

2) Allow per-request handling of Mojo connection errors. The alternative is to keep an external list of all Mojo requests and deal with them in a connection error handler. Either method works but adding additional request tracking state may be easier on a per-request basis than globally for some code.

Outside of Mojo I'm not as familiar with cases where this pattern is useful.