First step towards support for being able to interrupt a running Dart Isolate

First step towards support for being able to interrupt a running Dart Isolate
using the debugger API
- restructure the debug connection handler code to allow a native thread
  to accept debug connections and read debug commands
- added a new message queue data structure for being able to dispatch
  debug commands on a per isolate basis
- add framework for generic commands and isolate specific commands.
Committed: https://code.google.com/p/dart/source/detail?r=13186

[hausner, 2012-09-28 17:03:01]

I like the way the code has been refactored. Nice!

LGTM with comment about message handling order.

https://codereview.chromium.org/10990089/diff/2003/runtime/bin/dbg_message.cc
File runtime/bin/dbg_message.cc (right):

https://codereview.chromium.org/10990089/diff/2003/runtime/bin/dbg_message.cc...
runtime/bin/dbg_message.cc:794: msglist_ = msg;
It seems that you are inserting the message at the beginning of the list. Does
that mean you will process then in the reverse order than they arrive? Is that
intended?

https://codereview.chromium.org/10990089/diff/2003/runtime/bin/dbg_message.cc...
runtime/bin/dbg_message.cc:815: resume_requested = msg->request_resume();
This is the only place where you need to know whether the VM has been told to
resume execution. Why not return that from HandleMessage()?

https://codereview.chromium.org/10990089/diff/2003/runtime/bin/dbg_message.cc...
runtime/bin/dbg_message.cc:862: // TODO(asiva): Get rid of this statis variabel
one we have a means
static variable

https://codereview.chromium.org/10990089/diff/2003/runtime/bin/dbg_message.h
File runtime/bin/dbg_message.h (right):

https://codereview.chromium.org/10990089/diff/2003/runtime/bin/dbg_message.h#...
runtime/bin/dbg_message.h:79: bool request_resume() const { return
request_resume_; }
It's a matter of taste, but I would eliminate the baroqueness of a setter for
request_resume. The field is set by its own class only.

I also don't like that request_resume() is a simple getter, since the value
returned is only correct once the message has been handled. How about returning
this value as a result from HandleMessage()?

[siva, 2012-09-28 23:32:29]

Thanks.

Good point about the message handling order.

https://chromiumcodereview.appspot.com/10990089/diff/2003/runtime/bin/dbg_mes...
File runtime/bin/dbg_message.cc (right):

https://chromiumcodereview.appspot.com/10990089/diff/2003/runtime/bin/dbg_mes...
runtime/bin/dbg_message.cc:794: msglist_ = msg;
Very good point. That was not intentional...
Changed code to add new messages at the end.

On 2012/09/28 17:03:01, hausner wrote:
> It seems that you are inserting the message at the beginning of the list. Does
> that mean you will process then in the reverse order than they arrive? Is that
> intended?

https://chromiumcodereview.appspot.com/10990089/diff/2003/runtime/bin/dbg_mes...
runtime/bin/dbg_message.cc:815: resume_requested = msg->request_resume();
HandleMessage() now returns true to indicate a resume has been requested, false
otherwise.

On 2012/09/28 17:03:01, hausner wrote:
> This is the only place where you need to know whether the VM has been told to
> resume execution. Why not return that from HandleMessage()?

https://chromiumcodereview.appspot.com/10990089/diff/2003/runtime/bin/dbg_mes...
runtime/bin/dbg_message.cc:862: // TODO(asiva): Get rid of this statis variabel
one we have a means
On 2012/09/28 17:03:01, hausner wrote:
> static variable

Done.

https://chromiumcodereview.appspot.com/10990089/diff/2003/runtime/bin/dbg_mes...
File runtime/bin/dbg_message.h (right):

https://chromiumcodereview.appspot.com/10990089/diff/2003/runtime/bin/dbg_mes...
runtime/bin/dbg_message.h:79: bool request_resume() const { return
request_resume_; }
On 2012/09/28 17:03:01, hausner wrote:
> It's a matter of taste, but I would eliminate the baroqueness of a setter for
> request_resume. The field is set by its own class only.
> 
> I also don't like that request_resume() is a simple getter, since the value
> returned is only correct once the message has been handled. How about
returning
> this value as a result from HandleMessage()?

Done.

[siva, 2012-10-03 01:24:05]

Synched up with top of tree and resolved conflicts.