[go-nuts] Re: Unexpect deadlock on select multi channel ?

[buaa . cch]

I think this is a bug, I change the logic of main goroutine and the other 
goroutine, then the deadlock disappeared
```go
package main

import (
"fmt"
"time"
)

var (
source = make(chan int)
idle   = make(chan int, 1)
)

func main() {
go func() {
for {
select {
case worker := <-source:
idle <- worker

case worker := <-idle:
fmt.Println(worker)
go func() {
time.Sleep(time.Second)
idle <- 1

}()
}
}

}()
for i := 0; i < 2; i++ {
source <- i

}

time.Sleep(time.Second * 10)

}

```

在 2018年2月7日星期三 UTC+8下午10:38:41，Damon Zhao写道：
>
> Please answer these questions before submitting your issue. Thanks!
> What version of Go are you using (go version)?
>
> go version go1.9.3 darwin/amd64
> Does this issue reproduce with the latest release?
>
> yes
> What operating system and processor architecture are you using (go env)?
> GOARCH="amd64"
> GOBIN=""
> GOEXE=""
> GOHOSTARCH="amd64"
> GOHOSTOS="darwin"
> GOOS="darwin"
> GOPATH="/Users/ariesdevil/Dropbox/workspace/go_workspace"
> GORACE=""
> GOROOT="/usr/local/Cellar/go/1.9.3/libexec"
> GOTOOLDIR="/usr/local/Cellar/go/1.9.3/libexec/pkg/tool/darwin_amd64"
> GCCGO="gccgo"
> CC="clang"
> GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments 
> -fmessage-length=0 
> -fdebug-prefix-map=/var/folders/h2/xl15t9g94tgfwclshzl086bhgp/T/go-build125147941=/tmp/go-build
>  
> -gno-record-gcc-switches -fno-common"
> CXX="clang++"
> CGO_ENABLED="1"
> CGO_CFLAGS="-g -O2"
> CGO_CPPFLAGS=""
> CGO_CXXFLAGS="-g -O2"
> CGO_FFLAGS="-g -O2"
> CGO_LDFLAGS="-g -O2"
> PKG_CONFIG="pkg-config"
>
> What did you do?
>
> code1: play.golang.org/p/8rcO11QS8un (@ianlancetaylor answerd at 
> https://github.com/golang/go/issues/23728#issuecomment-363771924)
>
>
> code2: https://play.golang.org/p/fJXhK8w22uu
>
> Above code2 sometimes run perfect and sometimes deadlock on my machine.
>
>
> 
>
>
>
> But if I put it in a goroutine, the result is confused:
>
>
> https://play.golang.org/p/oUmMr8TM2sz  success
>
> https://play.golang.org/p/54eLI7x5FwD failed
>
>
> notice line 25 when I use
>
> ```
>
> case worker := <-source:
>
> idle <- worker
>
> ```
>
> instead of:
>
> ```
>
> case idle <- <-source:
>
> ```
>
> it works.
> What did you expect to see?
>
> I think it should not deadlock.
> What did you see instead?
> deadlock sometimes.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Unexpect deadlock on select multi channel ?

[buaa . cch]

sorry for misunderstanfing.. this is not a bug...

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] question about asm doc

[buaa . cch]

Official doc (golang.org/doc/asm) said that:

The SP pseudo-register is a virtual stack pointer used to refer to 
frame-local variables and the arguments being prepared for function calls. 
It points to the top of the local stack frame, so references should use 
negative offsets in the range [−framesize, 0): x-8(SP), y-4(SP), and so on.

And I've found a slide introduce the amd64 stack frame layout.


So, is the -framesize a correct value? If I count from the SP(virtual 
register), the min address will exceed the stack frame address range.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] question about asm doc

[buaa . cch]

here:
https://github.com/golang/go/files/447163/GoFunctionsInAssembly.pdf

在 2018年4月17日星期二 UTC+8下午10:15:07，Ian Lance Taylor写道：
>
> On Tue, Apr 17, 2018 at 5:33 AM, > wrote: 
> > 
> > Official doc (golang.org/doc/asm) said that: 
> > 
> > The SP pseudo-register is a virtual stack pointer used to refer to 
> frame-local variables and the arguments being prepared for function calls. 
> It points to the top of the local stack frame, so references should use 
> negative offsets in the range [−framesize, 0): x-8(SP), y-4(SP), and so on. 
> > 
> > And I've found a slide introduce the amd64 stack frame layout. 
> > 
> > So, is the -framesize a correct value? If I count from the SP(virtual 
> register), the min address will exceed the stack frame address range. 
>
> I don't think the diagram you are looking at describes how the Go 
> assembler works.  I note that it seems to say IBM on the side.  Where 
> did you find the diagram? 
>
> Ian 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] question about asm doc

[buaa . cch]

I also wonder if there are some official doc about this stack layout on 
amd64..

在 2018年4月18日星期三 UTC+8上午3:48:46，Ian Lance Taylor写道：
>
> On Tue, Apr 17, 2018 at 9:46 AM,  > 
> wrote: 
> > here: 
> > https://github.com/golang/go/files/447163/GoFunctionsInAssembly.pdf 
>
> OK, you'll have to ask Michael Munday, CC'ed. 
>
> Ian 
>
> > 在 2018年4月17日星期二 UTC+8下午10:15:07，Ian Lance Taylor写道： 
> >> 
> >> On Tue, Apr 17, 2018 at 5:33 AM,  wrote: 
> >> > 
> >> > Official doc (golang.org/doc/asm) said that: 
> >> > 
> >> > The SP pseudo-register is a virtual stack pointer used to refer to 
> >> > frame-local variables and the arguments being prepared for function 
> calls. 
> >> > It points to the top of the local stack frame, so references should 
> use 
> >> > negative offsets in the range [−framesize, 0): x-8(SP), y-4(SP), and 
> so on. 
> >> > 
> >> > And I've found a slide introduce the amd64 stack frame layout. 
> >> > 
> >> > So, is the -framesize a correct value? If I count from the SP(virtual 
> >> > register), the min address will exceed the stack frame address range. 
> >> 
> >> I don't think the diagram you are looking at describes how the Go 
> >> assembler works.  I note that it seems to say IBM on the side.  Where 
> >> did you find the diagram? 
> >> 
> >> Ian 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "golang-nuts" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to golang-nuts...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Does runtime.RaceDisable not work in non-std library ?

[buaa . cch]

package main
import "runtime"
var a int
func calc() {
for i := 0; i < 10; i++ {
go func() {
for {
runtime.RaceDisable()
a++
runtime.RaceEnable()
}
}()

}
}
func main() {
calc()
}

go run -race a.go


在 2018年8月22日星期三 UTC+8下午10:34:35，Ian Lance Taylor写道：
>
> On Wed, Aug 22, 2018 at 3:25 AM,  > wrote: 
> > 
> > When I copy the sync.Pool's source code in a repo, and using 
> `//go:linkname` 
> > link those runtime functions manually. 
> > When I run `go test -race`, it reports `DATA RACE`. 
> > But the sync.Pool with the same test case does not report  `DATA RACE`. 
> > 
> > Does runtime.RaceDisable not work in non-std library ? 
>
> It should work.  I think you'll have to show us your code. 
>
> Ian 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.