Add pause methods to Isolate.

Add pause methods to Isolate.

R=floitsch@google.com

Committed: https://code.google.com/p/dart/source/detail?r=32351

[Lasse Reichstein Nielsen, 2014-02-04 11:56:52]

The is a suggested design for pause.
It requires the pause capability in the Isolate in order to pause, and it uses a
second capability to identify the pause.
That second capability is used to resume again, no pause capability required (so
you can let someone else resume an isolate without giving them the ability to
pause it).

The isolate needs to maintain a collection of the currently active pause
capabilities. When pausing on a capability, it is added. When resuming on a
capability, it is removed again, and if there are no further pauses, the isolate
resumes handling events.

The only sequencing requirement I put on the control message is that it will be
handled before any later SendPort and control port sends from the current
isolate to the same isolate. 
Is this possible and reasonable?

[floitsch, 2014-02-04 12:39:24]

LGTM.

https://codereview.chromium.org/142703010/diff/1/sdk/lib/isolate/isolate.dart
File sdk/lib/isolate/isolate.dart (right):

https://codereview.chromium.org/142703010/diff/1/sdk/lib/isolate/isolate.dart...
sdk/lib/isolate/isolate.dart:38: * The accepted messages of a control port are
all lists containing
I would prefer not to expose the protocol just yet.

This means that normal receive-ports need to filter out control messages (and
similarly control receive-ports need to filter out non-control messages).

https://codereview.chromium.org/142703010/diff/1/sdk/lib/isolate/isolate.dart...
sdk/lib/isolate/isolate.dart:130: * Sends a message to an isolate requresting
that it ends a pause
requesting

https://codereview.chromium.org/142703010/diff/1/sdk/lib/isolate/isolate.dart...
sdk/lib/isolate/isolate.dart:132: * The resume will happen eventually, but not
necessarily right away.
Remove that line.

https://codereview.chromium.org/142703010/diff/1/tests/isolate/pause_test.dart
File tests/isolate/pause_test.dart (right):

https://codereview.chromium.org/142703010/diff/1/tests/isolate/pause_test.dar...
tests/isolate/pause_test.dart:35: return new Future.delayed(const
Duration(milliseconds: 250));
no need to wait that long. Reduce to 50 or 100ms.

[Lasse Reichstein Nielsen, 2014-02-04 14:02:28]

https://codereview.chromium.org/142703010/diff/1/sdk/lib/isolate/isolate.dart
File sdk/lib/isolate/isolate.dart (right):

https://codereview.chromium.org/142703010/diff/1/sdk/lib/isolate/isolate.dart...
sdk/lib/isolate/isolate.dart:38: * The accepted messages of a control port are
all lists containing
I thought we were going to expose the control port and capabilities.
Will we make the control messages not be normal messages that the user can send
directly? I.e., wrapping in an "Isolate" is the only way to send the message
(which is not safe, because the user can implement SendPort and record the
message that way).

https://codereview.chromium.org/142703010/diff/1/sdk/lib/isolate/isolate.dart...
sdk/lib/isolate/isolate.dart:50: Isolate._fromControlPort(this.controlPort,
[this.pauseCapability]);
Should eventually be public.

[floitsch, 2014-02-04 16:57:48]

https://codereview.chromium.org/142703010/diff/1/sdk/lib/isolate/isolate.dart
File sdk/lib/isolate/isolate.dart (right):

https://codereview.chromium.org/142703010/diff/1/sdk/lib/isolate/isolate.dart...
sdk/lib/isolate/isolate.dart:38: * The accepted messages of a control port are
all lists containing
On 2014/02/04 14:02:29, Lasse Reichstein Nielsen wrote:
> I thought we were going to expose the control port and capabilities.
> Will we make the control messages not be normal messages that the user can
send
> directly? I.e., wrapping in an "Isolate" is the only way to send the message
> (which is not safe, because the user can implement SendPort and record the
> message that way).

If we are certain that this is the protocol we want to support, sure.
I would prefer not to expose it just yet. If users do some tricks to get to it,
that's fine. They can't expect it not to change, though.

[Lasse Reichstein Nielsen, 2014-02-06 09:47:42]

Committed patchset #2 manually as r32351 (presubmit successful).