[PERF] Ajax should join an existing run if one exists

[chadhietala]

Prior to this commit we would always create a new runloop, which would lead to nested runloops. Instead this will join a runloop if one is already running or create one if one does not exist.

[fivetanley]

So Ember has its own instance of Backburner.... I'm not sure what we should be using here. This is probably right, but I don't know enough about why we have our own instance.

cc @igorT @stefanpenner

[runspired]

There's a separate instance? ime ED has it's own queues, but those are added to the same instance. Or at least they were when I poked around a while back, probably around beta 18.

[fivetanley]

https://github.com/emberjs/data/blob/master/addon/system/store.js#L220

[krisselden]

@fivetanley this comes into play if you have cached or server side rendered response you fullfill the ajax with and already have a run loop.

[krisselden]

@chadhietala can you flatten?

[chadhietala]

@krisselden squashed.

[stefanpenner]

LGTM.

For those reading along ofcourse for most people this doesn't make a difference, But if they happen to batch multiple XHR at a lower layer then this, they can easily now wrap that base in a run, batching these higher level one.

[stefanpenner]

@fivetanley not to worry, that should not matter, the ED bb should stay the way it is. (at least for now)

@runspired it has its own bb instance, and the queues are not shared between instances. the aim was avoid plan interference of two different interleaving priority queues.

The ember bb queue, can run a task which triggers the ED queue to grow. At which time, the ED queue must flush entirely. This ensures the various multi-phase ED relationship synching steps can reach a consistent state before releasing back to ambient flush.

In theory with some changes to BB this could have been supported with 1 BB instance, but the current approach required no extra BB work, keeping the complexity down, and was semantically the same.

[bmac]

Thanks @chadhietala.