CL 414836 limited the check for implicit dot for method call enabled by
a type bound. However, the checking condition for ODOTMETH only is not
right. For example, for promoted method, we have a OXDOT node instead,
and we still have to check for implicit dot in this case.
However, if the base type and embedded types have the same method name,
e.g in issue #53419, typecheck.AddImplicitDots will be confused and
result in an ambigus selector.
To fix this, we ensure methods for the base type are computed, then only
do the implicit dot check if we can find a matched method.
Fixes#54348
Change-Id: Iefe84ff330830afe35c5daffd499824db108da23
Reviewed-on: https://go-review.googlesource.com/c/go/+/422274
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This saves 11,000 allocations when loading the standard library
in golang.org/x/tools/go/ssa form.
Change-Id: I8aa32b0641c1a3dde29e6ee76c760006035dd56d
Reviewed-on: https://go-review.googlesource.com/c/go/+/423934
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Alan Donovan <adonovan@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
This CL make math.sqrt an intrinsic function, math.Sqrt is not affected
since compiler can inline it. With this change, we can remove all assembly
code for math.Sqrt that aims to speed up indirect call. The go compiler can
generate same or faster code (with regabi) for indirect call.
Benchmark on amd64:
name old time/op new time/op delta
SqrtIndirect 2.60ns ± 3% 1.03ns ± 4% -60.24% (p=0.000 n=10+10)
SqrtLatency 3.40ns ± 1% 3.32ns ± 1% -2.26% (p=0.000 n=10+8)
SqrtIndirectLatency 6.09ns ± 0% 3.31ns ± 0% -45.67% (p=0.000 n=10+10)
SqrtGoLatency 36.1ns ± 6% 34.6ns ± 1% ~ (p=0.101 n=10+10)
SqrtPrime 2.53µs ± 2% 2.55µs ± 6% ~ (p=0.398 n=9+9)
Change-Id: If4be0f242c1d9d4feca7d269fc9cd6e6066f163d
Reviewed-on: https://go-review.googlesource.com/c/go/+/421074
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
addresses proposal #53084
required by sha-256 change list developed for #50543
Change-Id: I5454d746fce069a7a4993d70dc5b0a5544f8eeaf
Reviewed-on: https://go-review.googlesource.com/c/go/+/408794
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@google.com>
Due to the latest binutils change [1], at least for certain 32-bit
relocs in .eh_frame section, this new type of relocation record is
emitted, leading to breakage on systems with bleeding-edge toolchain
when trying to link with object(s) with such new-style relocs.
Simply treating it the same as the existing reloc types seems enough.
Fixes#54222
[1]: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=f09482a8747b6fd4c2d59a6a64677d3a3fe1e092
Change-Id: I876d6711d5d4a674bead37e57f9503f1622d1136
Reviewed-on: https://go-review.googlesource.com/c/go/+/420983
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Single quotes don't account for whitespace in this context, which causes
output to look like this:
$ ./make.bat
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
Building Go cmd/dist using C:\Program Files\Go. (go version =)
When it should look like this:
Building Go cmd/dist using C:\Program Files\Go. (go1.19 windows/amd64)
For #44505.
Change-Id: I71328add5c74bd2829c0e23224cfa6252395ff2c
GitHub-Last-Rev: a01fda6b52
GitHub-Pull-Request: golang/go#54270
Reviewed-on: https://go-review.googlesource.com/c/go/+/421356
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The issue is expected to be fixed when Unified IR is enabled by default,
so adding a test to make sure thing works correctly.
Updates #53702
Change-Id: Id9d7d7ca4506103df0d10785ed5ee170d69988ba
Reviewed-on: https://go-review.googlesource.com/c/go/+/423434
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
We use EDNS(0) by default. No need to fall back to netdns=cgo if we
see a explicit request for EDNS(0) in resolv.conf.
For #51153
Change-Id: I135363112e3de43ce877aad45aba71d1448068b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/415579
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
The existing value for M1 is 64, which is the same as other arm64 cpus.
But the correct cacheLineSize for M1 should be 128, which can be
verified using the following command:
$ sysctl -a hw | grep cachelinesize
hw.cachelinesize: 128
Fixes#53075
Change-Id: Iaa8330010a4499b9b357c70743d55aed6ddb8588
GitHub-Last-Rev: df87eb9c50
GitHub-Pull-Request: golang/go#53076
Reviewed-on: https://go-review.googlesource.com/c/go/+/408576
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Meng Zhuo <mzh@golangcn.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Martin Möhrmann <martin@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Keith Randall <khr@google.com>
Change-Id: I79695e1cfda3b4cd911673f6e14dc316c451e2ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/423436
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Extra Ms may lead to the "no consistent ordering of events possible" error when parsing trace file with cgo enabled, since:
1. The gs in the extra Ms may be in `_Gdead` status while starting trace by invoking `runtime.StartTrace`,
2. and these gs will trigger `traceEvGoSysExit` events in `runtime.exitsyscall` when invoking go functions from c,
3. then, the events of those gs are under non-consistent ordering, due to missing the previous events.
Add two events, `traceEvGoCreate` and `traceEvGoInSyscall`, in `runtime.StartTrace`, will make the trace parser happy.
Fixes#29707
Change-Id: I7cc4b80822d2c46591304a59c9da2c9fc470f1d0
GitHub-Last-Rev: 445de8eaf3
GitHub-Pull-Request: golang/go#53284
Reviewed-on: https://go-review.googlesource.com/c/go/+/411034
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
The HTTP/1 server deletes multipart form tempfiles after ServeHTTP
returns, but the HTTP/2 server does not. Add a test to verify
cleanup happens in both cases, temporarily disabled for the
HTTP/2 path.
For #20253
Updates #25965
Change-Id: Ib753f2761fe73b29321d9d4337dbb5090fd193c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/423194
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Two packages construct atomic booleans from atomic integers.
Replace these implementations with the new atomic.Bool type.
Indeed, these packages were the impetus for the new atomic.Bool
type, having demonstrated a need to access boolean values
atomically.
Change-Id: I6a0314f8e7d660984a6daf36a62ed05a0eb74b2f
Reviewed-on: https://go-review.googlesource.com/c/go/+/411400
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
When ReverseProxy forwards a request with no User-Agent header, leave
the header in the forwarded request blank rather than inserting the
default Go HTTP clent User-Agent.
We already did this for NewSingleHostReverseProxy; generalize it to
every ReverseProxy.
Change-Id: Id81a230cb8d384acdfae190b78a4265d80720388
Reviewed-on: https://go-review.googlesource.com/c/go/+/407375
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
X-Forwarded-Host contains the original request's host.
X-Forwarded-Proto contains "http" or "https", depending on whether the
original request was made on a TLS-secured connection.
Setting either header to nil in Director disables adding the header,
same as for X-Forwarded-For.
Fixes#50465.
Change-Id: If8ed1f48d83f8ea0389c53519bc7994cb53891db
Reviewed-on: https://go-review.googlesource.com/c/go/+/407414
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The current implementation ignores cookies where the
cookie name starts or ends with a space. For example,
name =value
is ignored.
I have come across pages that send cookies in this weird format.
I tested with the latest versions of Firefox, Safari and Chrome,
all of which accept cookies in this format.
To do this, I remove leading and trailing spaces from the
cookie name after cutting at '='.
Change-Id: I8fd0c37a2113b6ce75712dd43607d1ea55e86c68
GitHub-Last-Rev: 368f50fcb4
GitHub-Pull-Request: golang/go#52121
Reviewed-on: https://go-review.googlesource.com/c/go/+/397734
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
CL 310850 dropped work re-checks on non-spinning Ms to fix#43997.
This introduced a new race condition: a non-spinning M may drop its P
and then park at the same time a spinning M attempts to wake a P to
handle some new work. The spinning M fails to find an idle P (because
the non-spinning M hasn't quite made its P idle yet), and does nothing
assuming that the system is fully loaded. This results in loss of work
conservation. In the worst case we could have a complete deadlock if
injectglist fails to wake anything just as all Ps are going idle.
sched.needspinning adds new synchronization to cover this case. If work
submission fails to find a P, it sets needspinning to indicate that a
spinning M is required. When non-spinning Ms prepare to drop their P,
they check needspinning and abort going idle to become a spinning M
instead. This addresses the race without extra spurious wakeups. In the
normal (non-racing case), an M will become spinning via the normal path
and clear the flag.
injectglist must change in addition to wakep because it is a similar
form of work submission, notably used following netpoll at a point when
we might not have a P that would guarantee the work runs.
Fixes#45867
Change-Id: Ieb623a6d4162fb8c2be7b4ff8acdebcc3a0d69a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/389014
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
This converts several unsynchronized reads (reads without holding
prof.signalLock) into atomic reads.
For #53821.
For #52912.
Change-Id: I421b96a22fbe26d699bcc21010c8a9e0f4efc276
Reviewed-on: https://go-review.googlesource.com/c/go/+/420196
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
I've dropped the note that sched.timeToRun is protected by sched.lock,
as it does not seem to be true.
For #53821.
Change-Id: I03f8dc6ca0bcd4ccf3ec113010a0aa39c6f7d6ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/419449
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
This converts a few unsynchronized accesses.
For #53821.
Change-Id: Ie2728779111e3e042696f15648981c5d5a86ca6d
Reviewed-on: https://go-review.googlesource.com/c/go/+/419448
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Note that this replaces numerous unsynchronized loads throughout the
scheduler.
For #53821.
Change-Id: Ica80b04c9e8c184bfef186e549526fc3f117c387
Reviewed-on: https://go-review.googlesource.com/c/go/+/419447
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Note that this converts nmspinning from uint32 to int32 for consistency
with the other count fields in schedt.
For #53821.
Change-Id: Ia6ca7a2b476128eda3b68e9f0c7775ae66c0c744
Reviewed-on: https://go-review.googlesource.com/c/go/+/419446
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Note that this converts npidle from uint32 to int32 for consistency with
the other count fields in schedt and the type of p.id.
Note that this changes previously unsynchronized operations to
synchronized operations in:
* handoffp
* injectglist
* schedtrace
* schedEnableUser
* sync_runtime_canSpin
For #53821.
Change-Id: I36d1b3b4a28131c9d47884fade6bc44439dd6937
Reviewed-on: https://go-review.googlesource.com/c/go/+/419445
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Note that this converts ngsys from uint32 to int32 to match the other
(non-atomic) counters.
For #53821.
Change-Id: I3acbfbbd1dabc59b0ea5ddc86a97e0d0afa9f80c
Reviewed-on: https://go-review.googlesource.com/c/go/+/419444
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Note that this converts pollUntil from uint64 to int64, the type used by
nanotime().
For #53821.
Change-Id: Iec9ec7e09d3350552561d0708ba6ea9e8a8ae7ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/419443
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Note that this changes the type from uint64 to int64, the type used by
nanotime(). It also adds an atomic load in pollWork(), which used to use
a non-atomic load.
For #53821.
Change-Id: I6173c90f20bfdc0e0a4bc3a7b1c798d1c429fff5
Reviewed-on: https://go-review.googlesource.com/c/go/+/419442
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We currently print these as -1, but some are technically uint64. We can
be more explicit about their irrelevance by printing 'nil' rather than
-1.
Change-Id: I267fd8830564c75032bfe9176af59047f5a90202
Reviewed-on: https://go-review.googlesource.com/c/go/+/419441
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
schedt.goidgen and p.goidcache are already uint64, this makes all cases
consistent.
The only oddball here is schedtrace which prints -1 as an equivalent for
N/A or nil. A future CL will make this more explicit.
Change-Id: I489626f3232799f6ca333d0d103b71d9d3aa7494
Reviewed-on: https://go-review.googlesource.com/c/go/+/419440
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
If a program only uses ecdh.P256(), the implementation of the other
curves shouldn't end up in the binary. This mostly required moving some
operations from init() time. Small performance hit in uncompressed
Bytes/SetBytes, but not big enough to show up in higher-level
benchmarks. If it becomes a problem, we can fix it by pregenerating the
p-1 bytes representation in generate.go.
For #52182
Updates #52221
Change-Id: I64460973b59ee3df787d7e967a6c2bcbc114ba65
Reviewed-on: https://go-review.googlesource.com/c/go/+/402555
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Fernando Lobato Meeser <felobato@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
We use crypto/internal/edwards25519/field to implement X25519 directly,
so that golang.org/x/crypto/curve25519 can be dropped from the src
module dependencies, and eventually replaced with a crypto/ecdh wrapper,
removing the need to keep golang.org/x/crypto/curve25519/internal/field
in sync with crypto/internal/edwards25519/field.
In crypto/internal/nistec, we add BytesX to serialize only the x
coordinate, which we'll need for the horrible ECDSA x-coord-to-scalar
operation, too.
In crypto/tls, we replace the ECDHE implementation with crypto/ecdh,
dropping the X25519 special cases and related scaffolding.
Finally, FINALLY, we deprecate the ~white whale~ big.Int-based APIs of
the crypto/elliptic package. •_•) ( •_•)>⌐■-■ (⌐■_■)
Fixes#52182Fixes#34648Fixes#52221
Change-Id: Iccdda210319cc892e96bb28a0e7b7123551982c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/398914
Reviewed-by: Fernando Lobato Meeser <felobato@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
ONAME nodes are shared, so using their position for anything is almost
always a mistake. There are probably more instances of this mistake
elsewhere. For now, handle the case of map key temporaries, where it's
been a problem.
Fixes#53456.
Change-Id: Id44e845d08d428592ad3ba31986635b6b87b0041
Reviewed-on: https://go-review.googlesource.com/c/go/+/417076
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
For #47653Fixes#45599Fixes#52522
Change-Id: Id6a80186434080cb0a205978ad7f224252674604
Reviewed-on: https://go-review.googlesource.com/c/go/+/408679
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Now that we've moved the trace locks to the leaf of the lock graph, we
can safely annotate that any trace event may acquire trace.lock even
if dynamically it turns out a particular event doesn't need to flush
and acquire this lock.
This reveals a new edge where we can trace while holding the mheap
lock, so we add this to the lock graph.
For #53789.
Updates #53979.
Change-Id: I13e2f6cd1b621cca4bed0cc13ef12e64d05c89a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/418720
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Now that trace.lock cannot be held over a stack split, we can move
that lock and traceStackTab to the leaf of the lock graph. We add a
couple edges to STACKGROW that were previously passing through trace.
Fixes#53979.
Change-Id: Ie664ff7bb33973745f991f7516dc6106e60f5892
Reviewed-on: https://go-review.googlesource.com/c/go/+/418957
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, trace.lock can be acquired while on a user G and stack
splits can happen while holding trace.lock. That means every lock used
by the stack allocator must be okay to acquire while holding
trace.lock, including various locks related to span allocation. In
turn, we cannot safely emit trace events while holding any
allocation-related locks because this would cause a cycle in the lock
rank graph.
To fix this, require that trace.lock only be acquired on the system
stack, like mheap.lock. This pushes it into the "bottom half" and
eliminates the lock rank relationship between tracing and stack
allocation, making it safe to emit trace events in many more places.
One subtlety is that the trace code has race annotations and uses
maps, which have race annotations. By default, we can't have race
annotations on the system stack, so we borrow the user race context
for these situations.
We'll update the lock graph itself in the next CL.
For #53979. This CL technically fixes the problem, but the lock rank
checker doesn't know that yet.
Change-Id: I9f5187a9c52a67bee4f7064db124b1ad53e5178f
Reviewed-on: https://go-review.googlesource.com/c/go/+/418956
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We're about to require that all uses of trace.lock be on the system
stack. That's mostly easy, except that it's involving parking the
trace reader. Fix this by changing that parking protocol so it instead
synchronizes through an atomic.
For #53979.
Change-Id: Icd6db8678dd01094029d7ad1c612029f571b4cbb
Reviewed-on: https://go-review.googlesource.com/c/go/+/418955
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
