[go-nuts] this code sometimes hangs

// I am not sure why this code sometimes deadlocks, but sometimes it doesn't. // Hopefully someone will have some suggestions package main // ??? sometimes deadlocks import ( "fmt" "sync" "time" ) type Button struct { Clicked *sync.Cond } func main() { button := Button{

[go-nuts] Mutex profiling question

I found this issue, https://github.com/golang/go/issues/57071 and tried running with GODEBUG=profileruntimelocks=1 but it made no difference in the output. I am using Go 1.22.4 on OSX. Any ideas how I can determine what is causing this high contention shown below: (pprof) tree Showing nodes

Re: [go-nuts] this code sometimes hangs

On Thu, Jul 18, 2024 at 4:24 PM Lammie Jonson wrote: > goroutineRunning.Done() Should be defer goroutineRunning.Done() (not tested) -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop rece

Re: [go-nuts] this code sometimes hangs

Because the wait on the condition is in another Go routine, so the the Broadcast occurs before all of the routines are waiting. Broadcast only wakes up currently waiting routines. > On Jul 18, 2024, at 9:01 AM, Lammie Jonson wrote: > > // I am not sure why this code sometimes deadlocks, but so

Re: [go-nuts] this code sometimes hangs

To clarify, the inner Go routine calls Done() at the start, so the main can get to the Broadcast before the inners are waiting. Which is what Jan’s fix will fix :) (pretty sure) > On Jul 18, 2024, at 10:20 AM, robert engels wrote: > > Because the wait on the condition is in another Go routine,

Re: [go-nuts] Mutex profiling question

Looks like the name was changed to runtimecontentionstacks Much better now… (pprof) tree Showing nodes accounting for 481.75ms, 100% of 481.75ms total Dropped 39 nodes (cum <= 2.41ms) --+- flat flat% sum%cum cu

[go-nuts] question about HACKING.md

In the document HACKING.md (https://github.com/golang/go/blob/master/src/runtime/HACKING.md), it states that we can determine if we're running on the user or system stack by running `getg() == getg().m.curg`. However if the output of that equality check is true, does that mean we're on user o

Re: [go-nuts] question about HACKING.md

On Thu, Jul 18, 2024 at 11:29 AM Leah Stapleton wrote: > > In the document HACKING.md > (https://github.com/golang/go/blob/master/src/runtime/HACKING.md), it states > that we can determine if we're running on the user or system stack by running > `getg() == getg().m.curg`. > > However if the ou

Re: [go-nuts] Mutex profiling question

Anyone have any idea on the high internal lock time on findRunnable?On Jul 18, 2024, at 10:36 AM, robert engels wrote:Looks like the name was changed to runtimecontentionstacksMuch better now…(pprof) treeShowing nodes accounting for 481.75ms, 100% of 481.75ms totalDropped 39 nodes (cum <= 2.41ms)

Re: [go-nuts] this code sometimes hangs

>> defer goroutineRunning.Done() This doesn't work. Each invocation of subscribe() has it's own sync.WaitGroup. It's just used it appears to ensure that the enclosed goroutine is running before subscribe() returns -- You received this message because you are subscribed to the Google Groups

Re: [go-nuts] this code sometimes hangs

But I think that Done() is for the outer which prevents the broadcast. By putting it in the defer all of the subscribers should be waiting on the condition when it occurs. Caveat- not looking at code - just remembering. On Jul 18, 2024, at 3:01 PM, Lammie Jonson wrote:>> defer goroutineRunning.Do

[go-nuts] go doc broken in official go repo

I cloned the official Go repo locally, went into src/text/template, ran `go doc .`, and got this error: go: downloading go1.23.0 (darwin/arm64) go: download go1.23.0 for darwin/arm64: toolchain not available It looks like src/go.mod declares 1.23. Shouldn't it be the latest self-host version, w

[go-nuts] runtime: found bad pointer in Go heap when not using CGO and -race reveals nothing

My go program does not use any CGO, but is failing rather consistently with the following error. Disabling the garbage collector with `debug.SetGCPercent(-1)` "fixes" the issue. The main dependencies used are [bubbletea](https://github.com/charmbracelet/bubbletea) and [pgx](https://github.com

Re: [go-nuts] go doc broken in official go repo

the bootstrap version only allows you to build enough of the compiler for it to run and build the rest of the distribution. you should be using the go binary built from the given source tree when interacting with it. - sean On Thu, Jul 18, 2024, 22:25 will@gmail.com wrote: > I cloned the of

Re: [go-nuts] Mutex profiling question

Hi Robert, First, note that the contention profile for runtime-internal locks doesn't correctly blame the part of the code that _caused_ delay: with Go 1.22 and 1.23, the call stacks are of (runtime-internal) lock users that _experienced_ delay. That's https://go.dev/issue/66999, and those odd

Re: [go-nuts] this code sometimes hangs

Hi, It’s better to not use sync.Cond. Instead, use a channel to do a jame job. There is even a issue to discuss remove it. 在2024年7月19日星期五 UTC+8 04:07:26 写道： > But I think that Done() is for the outer which prevents the broadcast. By > putting it in the defer all of the subscribers should be wai

[go-nuts] xrealwd() in unix.c in Go 1.4

Hi, I'm trying to learn how the last version of Go that is bootstrapped from C works and as a learning exercise, maybe try porting to a new OS (on x86 for now)... So I'm trying to get my head around the xrealdwd() function in /src/cmd/dist/unix.c - I just can't grok why it is needed. A q

Re: [go-nuts] xrealwd() in unix.c in Go 1.4

On Thu, Jul 18, 2024 at 9:38 PM Chris Guthrey wrote: > > I'm trying to learn how the last version of Go that is bootstrapped from C > works and as a learning exercise, maybe try porting to a new OS (on x86 for > now)... > > So I'm trying to get my head around the xrealdwd() function in > /src/