New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement _enqueueImmediate #9001

Closed
floitschG opened this Issue Mar 8, 2013 · 8 comments

Comments

Projects
None yet
7 participants
@floitschG
Contributor

floitschG commented Mar 8, 2013

In an upcoming commit the library uses "_enqueueImmediate" with the following properties:
/** Enqueues the given callback before any other event in the event-loop. */
static void _enqueueImmediate(void callback())

Callbacks register through this function are always executed in order and are guaranteed to run before other asynchronous events (like [Timer] events, or DOM events).

Note: currently it would be ok to only allow one callback at a time. If you chose to implement the function with this behavior please let me (floitsch) know and I will update the documentation to make sure it won't be used otherwise.

@iposva-google

This comment has been minimized.

Show comment
Hide comment
@iposva-google

iposva-google Jun 5, 2013

Contributor

Removed Priority-Medium label.
Added Priority-Unassigned label.

Contributor

iposva-google commented Jun 5, 2013

Removed Priority-Medium label.
Added Priority-Unassigned label.

@sethladd

This comment has been minimized.

Show comment
Hide comment
@sethladd

sethladd Aug 23, 2013

Member

Florian, is this important for 1.0?

Member

sethladd commented Aug 23, 2013

Florian, is this important for 1.0?

@DartBot

This comment has been minimized.

Show comment
Hide comment
@DartBot

DartBot Oct 7, 2014

This comment was originally written by @kaendfinger


Has this been fixed?

DartBot commented Oct 7, 2014

This comment was originally written by @kaendfinger


Has this been fixed?

@iposva-google

This comment has been minimized.

Show comment
Hide comment
@iposva-google

iposva-google Oct 8, 2014

Contributor

Added AssumedStale label.

Contributor

iposva-google commented Oct 8, 2014

Added AssumedStale label.

@stereotype441

This comment has been minimized.

Show comment
Hide comment
@stereotype441

stereotype441 Dec 9, 2014

Member

I don't think this bug is stale. It's still referred to from our public docs (https://www.dartlang.org/articles/event-loop/), and the incorrect behavior described there still exists under the VM (see https://www.dartlang.org/articles/event-loop/#question-2).

Here's a shorter repro:

  import 'dart:async';
  main() {
    new Future(() {
      print('Future 1');
      new Future.microtask(() => print('Microtask future'));
    });
    new Future(() => print('Future 2'));
  }

This code should print:

  Future 1
  Microtask future
  Future 2

since the microtask should execute before the event to print "Future 2" is popped off the event loop. This works correctly in Dart2js, but the VM prints:

  Future 1
  Future 2
  Microtask future


Added Triaged label.

Member

stereotype441 commented Dec 9, 2014

I don't think this bug is stale. It's still referred to from our public docs (https://www.dartlang.org/articles/event-loop/), and the incorrect behavior described there still exists under the VM (see https://www.dartlang.org/articles/event-loop/#question-2).

Here's a shorter repro:

  import 'dart:async';
  main() {
    new Future(() {
      print('Future 1');
      new Future.microtask(() => print('Microtask future'));
    });
    new Future(() => print('Future 2'));
  }

This code should print:

  Future 1
  Microtask future
  Future 2

since the microtask should execute before the event to print "Future 2" is popped off the event loop. This works correctly in Dart2js, but the VM prints:

  Future 1
  Future 2
  Microtask future


Added Triaged label.

@iposva-google

This comment has been minimized.

Show comment
Hide comment
@iposva-google

iposva-google Dec 9, 2014

Contributor

This is still AssumedStale.

The problem described in comment #­5 is due to how the Future(computation) is implemented. Futures scheduled within the same event will ALL be executed in the same run of the timer before returning to the event loop. Thus Future 1 and Future 2 will execute before any micro tasks fire. If you believe this is an error, then please file a bug against the Future implementation.


cc @floitschG.
cc @lrhn.
cc @skabet.
Added AssumedStale label.

Contributor

iposva-google commented Dec 9, 2014

This is still AssumedStale.

The problem described in comment #­5 is due to how the Future(computation) is implemented. Futures scheduled within the same event will ALL be executed in the same run of the timer before returning to the event loop. Thus Future 1 and Future 2 will execute before any micro tasks fire. If you believe this is an error, then please file a bug against the Future implementation.


cc @floitschG.
cc @lrhn.
cc @skabet.
Added AssumedStale label.

@lrhn

This comment has been minimized.

Show comment
Hide comment
@lrhn

lrhn Dec 10, 2014

Member

So two (or more) timers that are scheduled for the same time (zero-duration timers scheduled right after each other generally are) then they are executed as one top-level event, not two, and with no microtasks executed between them.

That does sound wrong. The reason for using a timer instead of a microtask is to allow top-level events between them (including browser redraw events).
Microtasks from one top-level event should execute before the next top-level event. By merging two top-level events into one, you prevent microtasks from being run in time.

This is not a Future issue, it's a Timer issue. The same behavior is exhibited by:

import 'dart:async';
main() {
  Timer.run(() {
    print("Timer 1");
    scheduleMicrotask(() => print("Microtask"));
  });
  Timer.run(() {
    print("Timer 2");
  });
}

I don't mind the merging of events that much (but it is surprising if it prevents redraw), but microtasks should still be run between the timer events.

That's not this bug, though. This bug was for making microtasks possible at all, which has been done.

Member

lrhn commented Dec 10, 2014

So two (or more) timers that are scheduled for the same time (zero-duration timers scheduled right after each other generally are) then they are executed as one top-level event, not two, and with no microtasks executed between them.

That does sound wrong. The reason for using a timer instead of a microtask is to allow top-level events between them (including browser redraw events).
Microtasks from one top-level event should execute before the next top-level event. By merging two top-level events into one, you prevent microtasks from being run in time.

This is not a Future issue, it's a Timer issue. The same behavior is exhibited by:

import 'dart:async';
main() {
  Timer.run(() {
    print("Timer 1");
    scheduleMicrotask(() => print("Microtask"));
  });
  Timer.run(() {
    print("Timer 2");
  });
}

I don't mind the merging of events that much (but it is surprising if it prevents redraw), but microtasks should still be run between the timer events.

That's not this bug, though. This bug was for making microtasks possible at all, which has been done.

@kwalrath

This comment has been minimized.

Show comment
Hide comment

This issue was closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment