Re: Fine grained task priorities on browser IO thread

[Gabriel Charette]

+task-sch...@chromium.org (brand new public list for discussions relevant to TaskScheduler)

On Mon, Nov 28, 2016 at 10:16 AM Gabriel Charette <g...@chromium.org> wrote:

Depends on the use case but I think WeakPtr is very far from an anti-pattern. For example it's very useful for tasks that can be cancelled. The relationship is very clear: "run this when it gets scheduled if it's still relevant".

It's not meant to "fix up" uncertain lifetime requirements, it's meant to encode specific cancellation-like semantics (which I now understand is not your use case so bad proposition on my part). Things that need to happen in a specific order should be sequenced (e.g. your example of cookie being set before request).

As for your specific situation of sharing a single H/2 connection (which you know better than I but I'm just tossing ideas), it sounds like resource sharing to me in which case ref-counting is better than sequencing all users and making the last one the "owner" in my opinion. Especially since, from what I understand, those users are otherwise independent(?). Forcing sequencing of unrelated tasks just because they use a shared resource and don't want to use ref-counting sounds to me like it's unnecessarily convoluting resource management with execution logic.

On Sun, Nov 27, 2016 at 1:53 AM Ryan Sleevi <rsl...@chromium.org> wrote:

On Thu, Nov 24, 2016 at 6:33 AM, Gabriel Charette <g...@chromium.org> wrote:

I see, maybe something WeakPtr based would work for this relationship (unless both absolutely need to happen but one uses the other's resources)? 

In general, I view WeakPtr as a bit of an anti-pattern. It's going from making a strong statement about lifetime/relationship to a more uncertain one. While this can be good for breaking up some dependencies, it's generally something that should come with a bit of a codesmell - because it means less logic can be intrinsically reasoned about. 

Yes, we can mitigate the lifetime issues with WeakPtr task-passing; but that doesn't resolve some of the synchronization events that, at least as currently structured for //net, have a definitive ordering (e.g. this cookie change is reflected before this request is sent)

 

Anyways, know that TaskScheduler can support splitting net's work into multiple sequences funneled to a single thread if you can address the lifetime issues (lifetime dependencies being encoded into the sequence itself is unfortunate).

Right, similar to above, I think lifetime dependencies encoded into the sequence are, from a readability/writability standpoint, the sort of ideal expression - because then you can't get it wrong :) WeakPtr says you hope you don't get it wrong, RefCounted says you don't care if you get it wrong, but base::Unretained() makes a commitment - you can't get it wrong (or else!) ;)

Yes, it does mean that there's a dependency tree of objects that you have to be aware of, and that certainly can lead to bugs. But at least the dependencies are explicit - WeakPtr doesn't really say much, and RefCounted means everything you thought you knew is a lie ;) In practice, the latter two seem to cause more issues around correctness, especially for async events, at least in Chromium.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.
To post to this group, send email to schedu...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/scheduler-dev/CACvaWvanY%3DT6atYQgr2DTr_tA8zva52W9tiUOqzjeH4A6WhZcg%40mail.gmail.com.

[Gabriel Charette]

Chatted offline with Ryan, we both learned a bunch from each other's use cases and paradigms and discussed how a future that would allow Lucky Luke to manage net/ could look like. Just thoughts and knowledge sharing at this point but here are the highlights: https://docs.google.com/document/d/1RbSchPHqXobDuUR2LTZrKTdkn7tiL5ogV4OJJZ9r1AQ/edit

Cheers,

Gab

[Gabriel Charette]

On Wed, Dec 14, 2016 at 11:49 AM Gabriel Charette <g...@chromium.org> wrote:

Chatted offline with Ryan, we both learned a bunch from each other's use cases and paradigms and discussed how a future that would allow Lucky Luke to manage net/ could look like. Just thoughts and knowledge sharing at this point but here are the highlights: https://docs.google.com/document/d/1RbSchPHqXobDuUR2LTZrKTdkn7tiL5ogV4OJJZ9r1AQ/edit

Argh, copy/paste overwrite changed text but not hyperlink... here's the public link : https://docs.google.com/document/d/1RbSchPHqXobDuUR2LTZrKTdkn7tiL5ogV4OJJZ9r1AQ/edit