code review 113110043: runtime: refactor routines for stopping, running gorout...

runtime: refactor routines for stopping, running goroutine from m

This CL adds 'dropg', which is called to drop the association
between m and its current goroutine, and it makes schedule
handle locked goroutines correctly, instead of requiring all
callers of schedule to do that.

The effect is that if you want to take over an m for, say,
garbage collection work while still allowing the current g
to run on some other m, you can do an mcall to a function
that is:

        // dissociate gp
        dropg();
        gp->status = Gwaiting; // for ready

        // put gp on run queue for others to find
        runtime·ready(gp);

        /* ... do other work here ... */

        // done with m, let it run goroutines again
        schedule();

Before this CL, the dropg() body had to be written explicitly,
and the check for lockedg before schedule had to be
written explicitly too, both of which make the code a bit
more fragile than it needs to be.

[rsc, 2014-07-14 21:43:08]

Hello dvyukov, iant (cc: golang-codereviews@googlegroups.com, rlh@golang.org),

I'd like you to review this change to
https://code.google.com/p/go/

[iant, 2014-07-15 00:13:33]

LGTM

[rsc, 2014-07-15 00:56:43]

*** Submitted as https://code.google.com/p/go/source/detail?r=13af066c1267 ***

runtime: refactor routines for stopping, running goroutine from m

This CL adds 'dropg', which is called to drop the association
between m and its current goroutine, and it makes schedule
handle locked goroutines correctly, instead of requiring all
callers of schedule to do that.

The effect is that if you want to take over an m for, say,
garbage collection work while still allowing the current g
to run on some other m, you can do an mcall to a function
that is:

        // dissociate gp
        dropg();
        gp->status = Gwaiting; // for ready

        // put gp on run queue for others to find
        runtime·ready(gp);

        /* ... do other work here ... */

        // done with m, let it run goroutines again
        schedule();

Before this CL, the dropg() body had to be written explicitly,
and the check for lockedg before schedule had to be
written explicitly too, both of which make the code a bit
more fragile than it needs to be.

LGTM=iant
R=dvyukov, iant
CC=golang-codereviews, rlh
https://codereview.appspot.com/113110043

[gobot, 2014-07-15 01:20:11]

This CL appears to have broken the nacl-amd64p32 builder.
See http://build.golang.org/log/4f9252fdaa9cce529cf80cf8387d3cc0518f162b

[dvyukov, 2014-07-15 06:26:36]

LGTM