Bug Tracker

Opened 12 years ago

Closed 11 years ago

#10467 closed feature (wontfix)

Deferreds should always resolve asynchronously

Reported by: scottgonzalez Owned by:
Priority: low Milestone: 1.9
Component: deferred Version: 1.6.4
Keywords: 1.8-discuss Cc:
Blocked by: #11013 Blocking: #12044

Description (last modified by Rick Waldron)

Deferreds should always be resolved asynchronously. Any abstraction that deals with a potentially async operation should always act asynchronously. The current implementation prevents users from writing code that takes advantage of async behavior and can cause bugs in bad code that is written against an initially synchronous implementation that later becomes asynchronous.

This also has the (positive) side effect of cached XHR requests in IE being resolved asynchronously.

Change History (18)

comment:1 Changed 12 years ago by scottgonzalez

Component: unfileddeferred
Summary: Deferreds should should always resolve asynchronouslyDeferreds should always resolve asynchronously

comment:2 Changed 12 years ago by jaubourg

I agree, but async=false in $.ajax() disagrees.

If we want to make Deferred 100% asynchronous, then we have to remove synchronous ajax requests (which I'd love to be able to do btw, but I doubt I'll see the day).

comment:3 Changed 12 years ago by scottgonzalez

Do we know if there's a lot of use of deferreds on sync XHR requests?

If we can't always force deferreds to resolve asynchronously, can we at least have an option during creation of the deferred for whether or not it should be forced to be async, with the default being async? Then sync XHR can set the flag and continue working as it does today.

comment:4 Changed 12 years ago by dmethvin

Status: newopen

comment:5 Changed 12 years ago by jaubourg

OK, so this is clearly about changing behaviour... do I wait for 1.8 for trying and fixing it or do I try it for 1.7? (async option was something I intended to add in $.Callbacks later on FYI)

comment:6 Changed 12 years ago by jaubourg

Blocked by: 11013 added
Keywords: 1.8-discuss added
Milestone: None1.8
Priority: undecidedlow

comment:7 Changed 12 years ago by jaubourg

Description: modified (diff)


comment:8 Changed 12 years ago by mikesherov


comment:9 Changed 12 years ago by Timmy Willison

+0, As I understand it, we are sometimes dependent on the synchronous nature of certain deferreds.

comment:10 Changed 12 years ago by Rick Waldron

Description: modified (diff)


comment:11 Changed 11 years ago by gnarf

I'm against this at this point, I can't use Deferred in animate any longer if it becomes async. No matter what we end up doing, It would break at least two use cases within jQuery core to not somehow still support the sync behavior.

comment:12 Changed 11 years ago by gnarf

I retract my earlier complaint under the assumption that this only causes a "async" step if it is resolved/rejected in the same event loop it was created in.

comment:13 Changed 11 years ago by scottgonzalez

@gnarf That is my intention. If the deferred is resolved in a future tick then the callbacks should be invoked in that same tick (synchronous with the resolution, but asynchronous compared to the creation of the deferred).

comment:14 Changed 11 years ago by dmethvin

Milestone: 1.81.9

Pushing to 1.9, current plan is to move the now-deprecated async:false option to a compat plugin which would allow $.Deferred to be totally async.

comment:15 Changed 11 years ago by tj@…

+1, if a callback may occur asynchronously to the code hooking it up, it should always occur asynchronously to that code. In fact, I recently file ticket #12044 because ready is chaotic in this respect.

comment:16 Changed 11 years ago by dmethvin

Type: enhancementfeature

Bulk change from enhancement to feature.

comment:17 Changed 11 years ago by jaubourg

Blocking: 12044 added

comment:18 Changed 11 years ago by dmethvin

Resolution: wontfix
Status: openclosed

In the email thread we had, it seemed like there was just too much potential for breaking lots of code (including cases currently in our own ajax and effects) so I don't think we can do this. Note that the Promise/A discussion leaves this intentionally unspecified.

Note: See TracTickets for help on using tickets.