]> Cypherpunks repositories - gostls13.git/commit
runtime: fix js/wasm lock implementation
authorMichael Anthony Knyszek <mknyszek@google.com>
Thu, 9 May 2019 19:55:39 +0000 (19:55 +0000)
committerMichael Knyszek <mknyszek@google.com>
Thu, 9 May 2019 20:22:27 +0000 (20:22 +0000)
commitcd03664f82a53dbe20d0b828189158ba3863039c
treecff96a71dce8368592857b53f52958372ddf4f14
parent0a2f72b8891d7203850cd7d2f52251edeb4dd747
runtime: fix js/wasm lock implementation

Trybots started failing on js/wasm after golang.org/cl/175797 landed,
but it seemed completely unrelated. It would fail very consistently on
the heapsampling.go test.

Digging deeper it was very difficult to ascertain what was going wrong,
but clearly m.locks for some m was non-zero when calling into the
scheduler.

The failure comes from the fact that lock calls into gosched, but it's
unclear how exactly we got there in the first place; there should be no
preemption in this single-threaded context.

Furthermore, lock shouldn't be calling gosched_m at all because in a
single-threaded context, the thread shouldn't be preempted until it
actually unlocks.

But, digging further it turns out the implementation in lock_js.go never
incremented or decremented m.locks. This is definitely wrong because
many parts of the runtime depend on that value being set correctly.

So, this change removes the loop which calls into gosched_m (which
should be unnecessary) and increments and decrements m.locks
appropriately. This appears to fix the aforementioned failure.

Change-Id: Id214c0762c3fb2b405ff55543d7e2a78c17443c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/176297
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
src/runtime/lock_js.go