Fine grained task priorities on browser IO thread

[Charles Harrison]

Hi scheduler-dev,

crbug.com/655585 shows a problem of task starvation on the IO thread when requesting many resources. When many requests are made at once, we have huge "chunks" of tasks which block requests from making progress. Here is a brief description of what we are seeing when requesting 100 resources over H2:

[ 100 OnResourceRequest tasks ] ~ 100ms

[ 100 OnStartCompleted tasks interleaved with certificate parsing tasks] ~ 250ms

[ 100 OnReadCompleted tasks] 

The OnResourceRequest tasks starve the OnStartCompleted / cert parsing tasks, which in turn starve the OnReadCompleted tasks. This results in cached responses coming in with a ~350-400ms delay!

My proposal in the bug is to assign priority to these tasks so that later tasks in the request lifecycle are given higher priority, so at least one request at any time is making forward progress. 

I looked briefly for an API in base/task_scheduler and I found TaskPriority which seems to be exactly what I want but is very coarse grained. To solve this we'd probably need more buckets with different semantics :/

Can we have some pointers for how best to proceed here? I would like to find a way to solve this without resorting to throttling requests / tasks, as I believe FIFO + priorities will produce optimal results.

[Ojan Vafai]

+Ian Kilpatrick +Dimitri Glazkov +Dru Knox FYI (also, should we use an ergonomics mailing list to CC for scalable loading discussions?)

--
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/CADjAqN7K11ROuywASJ0Zj-vBTu0UXFa7nXWdiG5-_Kqf1jm78w%40mail.gmail.com.

[Alex Clarke]

FYI The blink scheduler is moving towards CPU time budgets for various task runners.  E.g. we want to throttle background tabs to 1% of CPU, or while loading we might want to limit main thread composting tasks to 50% of CPU.

I'm not sure if that's a good match for you since it's at the task runner level, but I thought I'd mention it.

--

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

[Charles Harrison]

Yeah I thought about doing this by splitting up work into separate task runners with budgets, but since the tasks are all related (various stages of loading a resource from cache) I didn't think it was a great fit.

However, if we did somehow break the tasks into separate task runners that were round-robbin'ed, I think it would be a reasonable solution.

[Ojan Vafai]

+Chromium Loading Performance probably cares about the outcome here.

On Tue, Oct 18, 2016 at 5:14 AM Charles Harrison <cshar...@chromium.org> wrote:

Yeah I thought about doing this by splitting up work into separate task runners with budgets, but since the tasks are all related (various stages of loading a resource from cache) I didn't think it was a great fit.

However, if we did somehow break the tasks into separate task runners that were round-robbin'ed, I think it would be a reasonable solution.

On Tue, Oct 18, 2016 at 5:11 AM, Alex Clarke <alexc...@google.com> wrote:

FYI The blink scheduler is moving towards CPU time budgets for various task runners.  E.g. we want to throttle background tabs to 1% of CPU, or while loading we might want to limit main thread composting tasks to 50% of CPU.

I'm not sure if that's a good match for you since it's at the task runner level, but I thought I'd mention it.

On 17 October 2016 at 21:52, 'Charles Harrison' via scheduler-dev <schedu...@chromium.org> wrote:

Hi scheduler-dev,

crbug.com/655585 shows a problem of task starvation on the IO thread when requesting many resources. When many requests are made at once, we have huge "chunks" of tasks which block requests from making progress. Here is a brief description of what we are seeing when requesting 100 resources over H2:

[ 100 OnResourceRequest tasks ] ~ 100ms

[ 100 OnStartCompleted tasks interleaved with certificate parsing tasks] ~ 250ms

[ 100 OnReadCompleted tasks] 

The OnResourceRequest tasks starve the OnStartCompleted / cert parsing tasks, which in turn starve the OnReadCompleted tasks. This results in cached responses coming in with a ~350-400ms delay!

My proposal in the bug is to assign priority to these tasks so that later tasks in the request lifecycle are given higher priority, so at least one request at any time is making forward progress. 

I looked briefly for an API in base/task_scheduler and I found TaskPriority which seems to be exactly what I want but is very coarse grained. To solve this we'd probably need more buckets with different semantics :/

Can we have some pointers for how best to proceed here? I would like to find a way to solve this without resorting to throttling requests / tasks, as I believe FIFO + priorities will produce optimal results.

--

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/CADjAqN7K11ROuywASJ0Zj-vBTu0UXFa7nXWdiG5-_Kqf1jm78w%40mail.gmail.com.

--
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/CADjAqN72hcD18qfMfL__jbQJPjd-YSj%3Dx5OKx8Ki3dji6-7BqQ%40mail.gmail.com.

[Sami Kyostila]

+some folks for the question about more fine grained priorities in base/task_scheduler.

The Blink scheduler has the capability to assign different priorities to tasks, but I don't think we should try to run that scheduler on the IO thread because nowadays it's fully embedded inside Blink. A better option I believe is to extend task_scheduler to do what we need.

By the way, does mojo change things here at all? As far as I understand it would move this prioritization problem from the IO thread to the main thread?

- Sami

You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.
To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CANMdWTtwDCgmya1HB4twJSRpODYDawPscqzmTk6fL%2BBZFsV2PQ%40mail.gmail.com.

[Charles Harrison]

I agree with you about possibly extending task_scheduler, rather than the blink scheduler.

Mojo will change things, but the general idea is we're moving things away from both the IO and UI threads to a separate network service (which can possibly live in another process). As long as these tasks remain unprioritized and FIFO, you're right they will starve themselves in whatever task queue they are on :)

- Sami

--

To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@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/CADjAqN7K11ROuywASJ0Zj-vBTu0UXFa7nXWdiG5-_Kqf1jm78w%40mail.gmail.com.

--
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-dev+unsubscribe@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/CADjAqN72hcD18qfMfL__jbQJPjd-YSj%3Dx5OKx8Ki3dji6-7BqQ%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

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

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CANMdWTtwDCgmya1HB4twJSRpODYDawPscqzmTk6fL%2BBZFsV2PQ%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

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

To post to this group, send email to loadi...@chromium.org.

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

[Gabriel Charette]

About base/task_scheduler and base::TaskPriority:

1) Finer TaskPriority levels, we are thinking about that, the reason it's not currently the case is that it could cause starvation with current algorithm (proposed solution and discussion @ http://crbug.com/623683)

2) base/task_scheduler is still an experiment and currently only runs in the browser process, behind a flag. We want it to move the renderers soon but using it today will DCHECK.

3) If you don't need to be on the IO thread for interaction with other thread-unsafe objects that live there then a TaskRunner with ExecutionMode::SEQUENCED on task_scheduler may very well suit your need when we get there (please let us know, we're gathering use cases to help prioritize next steps).

Cheers,

Gab

- Sami

--

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/CADjAqN7K11ROuywASJ0Zj-vBTu0UXFa7nXWdiG5-_Kqf1jm78w%40mail.gmail.com.

--
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/CADjAqN72hcD18qfMfL__jbQJPjd-YSj%3Dx5OKx8Ki3dji6-7BqQ%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

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

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CANMdWTtwDCgmya1HB4twJSRpODYDawPscqzmTk6fL%2BBZFsV2PQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

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

To post to this group, send email to loadi...@chromium.org.

[Josh Karlin]

+net...@chromium.org 

The net/ stack team is still very interested in this for the IO thread in the browser process. Here is our use case:

Loading a resource has > 7 asynchronous steps (calls to PostTask). We'd like each step to have a higher task priority so that requests that start earlier get to finish earlier. Further, there are 5 request priority levels that a network request can run at. So we'd need say ~7x5 task priorities that we could assign just for the network stack on the browser IO thread. In order to not interfere with the non-networking IO tasks, we'd consider running all of our task priorities at below the default priority.

We're eager to be the first adopters of the task_scheduler, as we're seeing significant task starvation of high priority requests (hundreds of milliseconds). Any chance that finer grain priorities like this will be supported? And, when can we try it out? :)

Thanks!

Josh

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAJTZ7LLUh9EO-dF9A-66B1Uquyg%2BXEEhDaHR8duTva5DA4jkYA%40mail.gmail.com.

[Josh Karlin]

+Randy Smith 

[Josh Karlin]

After considering this further, and with helpful input from rsleevi@ (thanks!), it's become clear that there are many dragons to using the TaskScheduler on the IO thread. Namely, concerns of races of objects being deleted before the tasks that depend on them run due to prioritization. I think we'll try to find an alternative solution to the task starvation issue we're seeing.

[Robert Liao]

Just curious, what sorts of lifetime issues did you encounter?

+Randy Smith 

- Sami

--

To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@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/CADjAqN7K11ROuywASJ0Zj-vBTu0UXFa7nXWdiG5-_Kqf1jm78w%40mail.gmail.com.

--
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-dev+unsubscribe@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/CADjAqN72hcD18qfMfL__jbQJPjd-YSj%3Dx5OKx8Ki3dji6-7BqQ%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

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

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CANMdWTtwDCgmya1HB4twJSRpODYDawPscqzmTk6fL%2BBZFsV2PQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

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

To post to this group, send email to loadi...@chromium.org.

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

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

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

[Gabriel Charette]

FYI, the TaskScheduler and Blink scheduler teams have discussed the potential to eventually merge the two. In order for this to happen, TaskScheduler needs to be able to manage multiple sequences being funneled to a single thread (instead of sharded across multiple workers). In such a world you would manage ordering (through sequences) and the funnel being single-threaded you wouldn't get races between sequences either. Would that work for you?

[Ryan Sleevi]

On Wed, Nov 23, 2016 at 12:33 PM, Gabriel Charette <g...@chromium.org> wrote:

FYI, the TaskScheduler and Blink scheduler teams have discussed the potential to eventually merge the two. In order for this to happen, TaskScheduler needs to be able to manage multiple sequences being funneled to a single thread (instead of sharded across multiple workers). In such a world you would manage ordering (through sequences) and the funnel being single-threaded you wouldn't get races between sequences either. Would that work for you?

Perhaps I'm misunderstanding, but you'd still get races across sequences, right? For example, two URLRequests with independent H/2 streams that share a single H/2 connection on a single low-level transport socket, you'd still need to ensure that shutdown sequencing is properly ordered. So that if the processing for one task on one request (dispatched via PostTask) was preempted by another task that tore down the underlying object hierarchy, you would still end up with the same lifetime concerns, do you not?

[Gabriel Charette]

Things that need to happen in a specific order would need to be on the same sequence and posted to it in that specific order (just like they must be on today's IO thread sequence). If they are independent on all aspects but shutdown order then perhaps independent sequences is possible if something else ensures lifetime order (your specific example sounds like multiple things depending on one thing, i.e. ref-counting?).

--

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/CACvaWvYRnsNAkmVqeLVHDhpfZNjRu52%2BHYeCa4KDOmKsry-Fig%40mail.gmail.com.

[Ryan Sleevi]

No, it's not refcounting, it's a parent/child relationship.

That was a big part of today's discussion - that much of //net is itself strictly sequenced (that is, a single sequence), either implicitly or explicitly, and the reordering introduces all the complexities of lifetime management and correctness. That's not to say it can't be solved, but it's not an easy drop-in, as there is a whole cascade of relationships.

Put differently, //net needs a single, sequenced task runner, even for independent requests. This argues for a more explicit management of priorities (avoiding the task queue to manage that), which allows for better management of object lifetimes and guarantees.

On Wed, Nov 23, 2016 at 1:56 PM, Gabriel Charette <g...@chromium.org> wrote:

Things that need to happen in a specific order would need to be on the same sequence and posted to it in that specific order (just like they must be on today's IO thread sequence). If they are independent on all aspects but shutdown order then perhaps independent sequences is possible if something else ensures lifetime order (your specific example sounds like multiple things depending on one thing, i.e. ref-counting?).

Le mer. 23 nov. 2016 16:07, Ryan Sleevi <rsl...@chromium.org> a écrit :

On Wed, Nov 23, 2016 at 12:33 PM, Gabriel Charette <g...@chromium.org> wrote:

FYI, the TaskScheduler and Blink scheduler teams have discussed the potential to eventually merge the two. In order for this to happen, TaskScheduler needs to be able to manage multiple sequences being funneled to a single thread (instead of sharded across multiple workers). In such a world you would manage ordering (through sequences) and the funnel being single-threaded you wouldn't get races between sequences either. Would that work for you?

Perhaps I'm misunderstanding, but you'd still get races across sequences, right? For example, two URLRequests with independent H/2 streams that share a single H/2 connection on a single low-level transport socket, you'd still need to ensure that shutdown sequencing is properly ordered. So that if the processing for one task on one request (dispatched via PostTask) was preempted by another task that tore down the underlying object hierarchy, you would still end up with the same lifetime concerns, do you not?

--

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-dev+unsubscribe@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/CACvaWvYRnsNAkmVqeLVHDhpfZNjRu52%2BHYeCa4KDOmKsry-Fig%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.
To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAJTZ7LLDF4DkxN4h2kCwXZ%2Bst6r5TxTjY3voquG8DXbxPuM%2BgA%40mail.gmail.com.

[Gabriel Charette]

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

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

Le mer. 23 nov. 2016 17:41, Ryan Sleevi <rsl...@chromium.org> a écrit :

No, it's not refcounting, it's a parent/child relationship.

That was a big part of today's discussion - that much of //net is itself strictly sequenced (that is, a single sequence), either implicitly or explicitly, and the reordering introduces all the complexities of lifetime management and correctness. That's not to say it can't be solved, but it's not an easy drop-in, as there is a whole cascade of relationships.

Put differently, //net needs a single, sequenced task runner, even for independent requests. This argues for a more explicit management of priorities (avoiding the task queue to manage that), which allows for better management of object lifetimes and guarantees.

On Wed, Nov 23, 2016 at 1:56 PM, Gabriel Charette <g...@chromium.org> wrote:

Things that need to happen in a specific order would need to be on the same sequence and posted to it in that specific order (just like they must be on today's IO thread sequence). If they are independent on all aspects but shutdown order then perhaps independent sequences is possible if something else ensures lifetime order (your specific example sounds like multiple things depending on one thing, i.e. ref-counting?).

Le mer. 23 nov. 2016 16:07, Ryan Sleevi <rsl...@chromium.org> a écrit :

On Wed, Nov 23, 2016 at 12:33 PM, Gabriel Charette <g...@chromium.org> wrote:

FYI, the TaskScheduler and Blink scheduler teams have discussed the potential to eventually merge the two. In order for this to happen, TaskScheduler needs to be able to manage multiple sequences being funneled to a single thread (instead of sharded across multiple workers). In such a world you would manage ordering (through sequences) and the funnel being single-threaded you wouldn't get races between sequences either. Would that work for you?

Perhaps I'm misunderstanding, but you'd still get races across sequences, right? For example, two URLRequests with independent H/2 streams that share a single H/2 connection on a single low-level transport socket, you'd still need to ensure that shutdown sequencing is properly ordered. So that if the processing for one task on one request (dispatched via PostTask) was preempted by another task that tore down the underlying object hierarchy, you would still end up with the same lifetime concerns, do you not?

--

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/CACvaWvYRnsNAkmVqeLVHDhpfZNjRu52%2BHYeCa4KDOmKsry-Fig%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

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

To post to this group, send email to loadi...@chromium.org.

[Ryan Sleevi]

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.

[Gabriel Charette]

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.

--

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]

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

[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