dart2js does not wait for all ports to be closed

[DartBot]

This issue was originally filed by [email protected]

---

See tests/isolate/isolate2_negative_test.dart and tests/compiler/dart2js_extra/isolate2_negative_test.dart

[DartBot]

This comment was originally written by [email protected]

---

Actually it's the test framework that does not wait for all ports to be closed. When the main method is done, test_controller.js sends a message to the window to notify the test is done. It should actually check that there are no open receive ports before sending that message.

@ahe: is that something you're familiar with?

---

cc @peter-ahe-google.
cc @ricowind.
Removed Area-Dart2JS label.
Added Area-Test label.

[peter-ahe-google]

I'm not sure what is broken here: is it the test framework or the test?

The test framework assumes that a test is compete when main exits, or that a test tells the framework that this assumption is wrong.

I would fix this by adding a print statement to the beginning of the test: "unittest-wait-for-done". But I'm not sure if that is the right thing for this test.

[DartBot]

This comment was originally written by [email protected]

---

It's the test framework, test_controller.js should somehow know that there are open receive ports on the main isolate, and therefore wait for it. Currently, only the implementation of the isolate library knows that.

[peter-ahe-google]

How would test_controller.js know that there are no open ports in Dartium? Which event should it subscribe to that informs it that all ports are closed?

[DartBot]

This comment was originally written by [email protected]

---

Ah, I thought test_controller.js was only used with dart2js. Let me investigate why we're getting a different behavior than the VM then.

[floitschG]

Issue #7926 has been merged into this issue.

[floitschG]

Marked the test as flaky since it sometimes succeeds.

[DartBot]

This comment was originally written by [email protected]

---

Removed this from the M3 milestone.
Added this to the M4 milestone.

[DartBot]

This comment was originally written by [email protected]

---

Removed this from the M4 milestone.
Added this to the Later milestone.

[ricowind]

Is this still a problem?

[floitschG]

+Martin since he wrote the framework that works around this issue (pkg/async_helper).

---

cc @mkustermann.

[mkustermann]

See comments on Issue #12587.

[floitschG]

With the pkg/async_helper package asynchronous (including isolate) tests can now be tested correctly without relying on ReceivePorts keeping programs alive.

I'm reassigning this bug to dart2js in case we want dart2js programs to keep running if they have open receive ports (like the VM). It's not a testing problem anymore, since tests should just use the async-helper package.

Note: I'm going to rewrite the tests, so this is not about tests/isolate/isolate2_negative_test.dart and tests/compiler/dart2js_extra/isolate2_negative_test.dart anymore.

---

Removed this from the Later milestone.
Removed Area-Test label.
Added Area-Dart2JS label.

[DartBot]

This comment was originally written by [email protected]

---

Set owner to @floitschG.