Re: [go-nuts] I found a very strange code that would cause deadlocks and blocking，why???

2019-02-28 Thread fgergo 
If you haven't studied concurrency before, I can't recommend any tutorials.
To start to learn about concurrency, I'd first recommend _some_
reading and theoretical background.

Concurrency is a complex concept. A "10x" multiplier estimation
compared to e.g. structured programming is probably right, definitely
not a 2x and probably not a 100x. Don't expect to become _proficient_
in concurrent programming in a couple of hours. Probably you won't be
able to download a couple of examples and start tinkering with them
successfully.

A good start is maybe:
https://golang.org/doc/faq#csp

Then maybe this:
https://en.wikipedia.org/wiki/Communicating_sequential_processes

The book is available for free:
http://www.usingcsp.com/cspbook.pdf

Don't expect to absorb the whole book in a couple of hours, it might
take from a couple of weeks to a few month to start to see how much
you still don't know.

As soon as you get a general understanding of concurrent concepts,
you'll most probably find adequate tutorials for yourself.

(To add to what Jan asked: for sharing code on golang-nuts please
share links to play.golang.org.)


On 3/1/19, mountain...@gmail.com  wrote:
> Is there a recommended tutorial?
>
> 在 2019年3月1日星期五 UTC+8下午12:21:58，Robert Engels写道：
>>
>> I think it would be helpful if you learned more about concurrent
>> programming. It is 10x harder, even with the simplifications that Go
>> offers. If you don’t understand the concepts you are going to struggle.
>> Start with some tutorials and work your way up.
>>
>> On Feb 28, 2019, at 10:14 PM, mount...@gmail.com  wrote:
>>
>> This is the stack information printed when blocking, how to see which G
>> blocking program?
>>
>> SIGABRT: abort
>> PC=0x7fff9ceabbf2 m=0 sigcode=0
>>
>> goroutine 0 [idle]:
>> runtime.pthread_cond_wait(0x1967620, 0x19675e0, 0x7fff)
>> /usr/local/go/src/runtime/sys_darwin.go:302 +0x51
>> runtime.semasleep(0x, 0x7fff5fbff670)
>> /usr/local/go/src/runtime/os_darwin.go:63 +0x85
>> runtime.notesleep(0x19673e0)
>> /usr/local/go/src/runtime/lock_sema.go:167 +0xe3
>> runtime.stoplockedm()
>> /usr/local/go/src/runtime/proc.go:2165 +0x8a
>> runtime.schedule()
>> /usr/local/go/src/runtime/proc.go:2565 +0x2d9
>> runtime.park_m(0xc72480)
>> /usr/local/go/src/runtime/proc.go:2676 +0xae
>> runtime.mcall(0x105722b)
>> /usr/local/go/src/runtime/asm_amd64.s:299 +0x5b
>>
>> goroutine 1 [semacquire]:
>> sync.runtime_Semacquire(0xc27794)
>> /usr/local/go/src/runtime/sema.go:56 +0x39
>> sync.(*WaitGroup).Wait(0xc27794)
>> /usr/local/go/src/sync/waitgroup.go:130 +0x64
>> cmd/go/internal/work.(*Builder).Do(0xc00023b0e0, 0xc0003ee3c0)
>> /usr/local/go/src/cmd/go/internal/work/exec.go:174 +0x38e
>> cmd/go/internal/run.runRun(0x195c300, 0xc1e0e0, 0x1, 0x1)
>> /usr/local/go/src/cmd/go/internal/run/run.go:137 +0x55b
>> main.main()
>> /usr/local/go/src/cmd/go/main.go:219 +0x7d4
>>
>> goroutine 5 [syscall]:
>> os/signal.signal_recv(0x0)
>> /usr/local/go/src/runtime/sigqueue.go:139 +0x9f
>> os/signal.loop()
>> /usr/local/go/src/os/signal/signal_unix.go:23 +0x22
>> created by os/signal.init.0
>> /usr/local/go/src/os/signal/signal_unix.go:29 +0x41
>>
>> goroutine 50 [select]:
>> cmd/go/internal/work.(*Builder).Do.func2(0xc27794, 0xc00023b0e0,
>> 0xc0004b0620)
>> /usr/local/go/src/cmd/go/internal/work/exec.go:155 +0x12f
>> created by cmd/go/internal/work.(*Builder).Do
>> /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x36a
>>
>> goroutine 51 [select]:
>> cmd/go/internal/work.(*Builder).Do.func2(0xc27794, 0xc00023b0e0,
>> 0xc0004b0620)
>> /usr/local/go/src/cmd/go/internal/work/exec.go:155 +0x12f
>> created by cmd/go/internal/work.(*Builder).Do
>> /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x36a
>>
>> goroutine 52 [syscall]:
>> syscall.Syscall6(0x7, 0x12006, 0xc50c24, 0x0, 0xc0002f43f0, 0x0, 0x0,
>>
>> 0xc0002f43f0, 0x0, 0xce2400)
>> /usr/local/go/src/syscall/asm_darwin_amd64.s:41 +0x5
>> syscall.wait4(0x12006, 0xc50c24, 0x0, 0xc0002f43f0, 0x90, 0x1566d60,
>> 0x14cc401)
>> /usr/local/go/src/syscall/zsyscall_darwin_amd64.go:34 +0x7b
>> syscall.Wait4(0x12006, 0xc50c74, 0x0, 0xc0002f43f0, 0x0, 0x1, 0x1)
>> /usr/local/go/src/syscall/syscall_bsd.go:129 +0x51
>> os.(*Process).wait(0xc0002fd4a0, 0xc34a00, 0xc50cf8, 0x0)
>> /usr/local/go/src/os/exec_unix.go:38 +0x7b
>> os.(*Process).Wait(0xc0002fd4a0, 0x15b89c8, 0x15b89d0, 0x15b89c0)
>> /usr/local/go/src/os/exec.go:125 +0x2b
>> os/exec.(*Cmd).Wait(0xc00052da20, 0x0, 0x0)
>> /usr/local/go/src/os/exec/exec.go:465 +0x5b
>> os/exec.(*Cmd).Run(0xc00052da20, 0x50, 0xcdf7c0)
>> /usr/local/go/src/os/exec/exec.go:309 +0x5c
>> cmd/go/internal/base.RunStdin(0xcdf7c0, 0x1, 0x1)
>> /usr/local/go/src/cmd/go/internal/base/base.go:162 +0x11e
>>

Re: [go-nuts] I found a very strange code that would cause deadlocks and blocking，why???

2019-02-28 Thread mountainfpf 
Is there a recommended tutorial?

在 2019年3月1日星期五 UTC+8下午12:21:58，Robert Engels写道：
>
> I think it would be helpful if you learned more about concurrent 
> programming. It is 10x harder, even with the simplifications that Go 
> offers. If you don’t understand the concepts you are going to struggle. 
> Start with some tutorials and work your way up. 
>
> On Feb 28, 2019, at 10:14 PM, mount...@gmail.com  wrote:
>
> This is the stack information printed when blocking, how to see which G 
> blocking program?
>
> SIGABRT: abort
> PC=0x7fff9ceabbf2 m=0 sigcode=0
>
> goroutine 0 [idle]:
> runtime.pthread_cond_wait(0x1967620, 0x19675e0, 0x7fff)
> /usr/local/go/src/runtime/sys_darwin.go:302 +0x51
> runtime.semasleep(0x, 0x7fff5fbff670)
> /usr/local/go/src/runtime/os_darwin.go:63 +0x85
> runtime.notesleep(0x19673e0)
> /usr/local/go/src/runtime/lock_sema.go:167 +0xe3
> runtime.stoplockedm()
> /usr/local/go/src/runtime/proc.go:2165 +0x8a
> runtime.schedule()
> /usr/local/go/src/runtime/proc.go:2565 +0x2d9
> runtime.park_m(0xc72480)
> /usr/local/go/src/runtime/proc.go:2676 +0xae
> runtime.mcall(0x105722b)
> /usr/local/go/src/runtime/asm_amd64.s:299 +0x5b
>
> goroutine 1 [semacquire]:
> sync.runtime_Semacquire(0xc27794)
> /usr/local/go/src/runtime/sema.go:56 +0x39
> sync.(*WaitGroup).Wait(0xc27794)
> /usr/local/go/src/sync/waitgroup.go:130 +0x64
> cmd/go/internal/work.(*Builder).Do(0xc00023b0e0, 0xc0003ee3c0)
> /usr/local/go/src/cmd/go/internal/work/exec.go:174 +0x38e
> cmd/go/internal/run.runRun(0x195c300, 0xc1e0e0, 0x1, 0x1)
> /usr/local/go/src/cmd/go/internal/run/run.go:137 +0x55b
> main.main()
> /usr/local/go/src/cmd/go/main.go:219 +0x7d4
>
> goroutine 5 [syscall]:
> os/signal.signal_recv(0x0)
> /usr/local/go/src/runtime/sigqueue.go:139 +0x9f
> os/signal.loop()
> /usr/local/go/src/os/signal/signal_unix.go:23 +0x22
> created by os/signal.init.0
> /usr/local/go/src/os/signal/signal_unix.go:29 +0x41
>
> goroutine 50 [select]:
> cmd/go/internal/work.(*Builder).Do.func2(0xc27794, 0xc00023b0e0, 
> 0xc0004b0620)
> /usr/local/go/src/cmd/go/internal/work/exec.go:155 +0x12f
> created by cmd/go/internal/work.(*Builder).Do
> /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x36a
>
> goroutine 51 [select]:
> cmd/go/internal/work.(*Builder).Do.func2(0xc27794, 0xc00023b0e0, 
> 0xc0004b0620)
> /usr/local/go/src/cmd/go/internal/work/exec.go:155 +0x12f
> created by cmd/go/internal/work.(*Builder).Do
> /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x36a
>
> goroutine 52 [syscall]:
> syscall.Syscall6(0x7, 0x12006, 0xc50c24, 0x0, 0xc0002f43f0, 0x0, 0x0, 
> 0xc0002f43f0, 0x0, 0xce2400)
> /usr/local/go/src/syscall/asm_darwin_amd64.s:41 +0x5
> syscall.wait4(0x12006, 0xc50c24, 0x0, 0xc0002f43f0, 0x90, 0x1566d60, 
> 0x14cc401)
> /usr/local/go/src/syscall/zsyscall_darwin_amd64.go:34 +0x7b
> syscall.Wait4(0x12006, 0xc50c74, 0x0, 0xc0002f43f0, 0x0, 0x1, 0x1)
> /usr/local/go/src/syscall/syscall_bsd.go:129 +0x51
> os.(*Process).wait(0xc0002fd4a0, 0xc34a00, 0xc50cf8, 0x0)
> /usr/local/go/src/os/exec_unix.go:38 +0x7b
> os.(*Process).Wait(0xc0002fd4a0, 0x15b89c8, 0x15b89d0, 0x15b89c0)
> /usr/local/go/src/os/exec.go:125 +0x2b
> os/exec.(*Cmd).Wait(0xc00052da20, 0x0, 0x0)
> /usr/local/go/src/os/exec/exec.go:465 +0x5b
> os/exec.(*Cmd).Run(0xc00052da20, 0x50, 0xcdf7c0)
> /usr/local/go/src/os/exec/exec.go:309 +0x5c
> cmd/go/internal/base.RunStdin(0xcdf7c0, 0x1, 0x1)
> /usr/local/go/src/cmd/go/internal/base/base.go:162 +0x11e
> cmd/go/internal/run.buildRunProgram(0xc00023b0e0, 0xc0003ee3c0, 0x13999b3, 
> 0xc00023b150)
> /usr/local/go/src/cmd/go/internal/run/run.go:151 +0x26d
> cmd/go/internal/work.(*Builder).Do.func1(0xc0003ee3c0)
> /usr/local/go/src/cmd/go/internal/work/exec.go:107 +0x72
> cmd/go/internal/work.(*Builder).Do.func2(0xc27794, 0xc00023b0e0, 
> 0xc0004b0620)
> /usr/local/go/src/cmd/go/internal/work/exec.go:165 +0xbb
> created by cmd/go/internal/work.(*Builder).Do
> /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x36a
>
> goroutine 53 [select]:
> cmd/go/internal/work.(*Builder).Do.func2(0xc27794, 0xc00023b0e0, 
> 0xc0004b0620)
> /usr/local/go/src/cmd/go/internal/work/exec.go:155 +0x12f
> created by cmd/go/internal/work.(*Builder).Do
> /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x36a
>
> goroutine 24 [chan receive]:
> cmd/go/internal/base.processSignals.func1(0xc86f00)
> /usr/local/go/src/cmd/go/internal/base/signal.go:21 +0x34
> created by cmd/go/internal/base.processSignals
> /usr/local/go/src/cmd/go/internal/base/signal.go:20 +0x93
>
> rax0x104
> rbx0xea00
> rcx0x7fff5fbff488
> rdx0xea00
> rdi0x1967620
> rsi0xea01eb00
> rbp

Re: [go-nuts] Will a pointer point to C.xxx be garbage collected by Go runtime？

2019-02-28 Thread Jan Mercl 
On Fri, Mar 1, 2019 at 6:37 AM Cholerae Hu  wrote:

> Will 'a' be scanned by go runtime?

Yes.

> It is allocate by go runtime.

Correct and that's the reason the GC will handle it normally.

> If p is scanned, go runtime should throw a 'bad pointer' error, because
the memory pointed by p is allocated by C.malloc, not go runtime.

The GC knows that p points to memory not obtained from Go runtime and will
not consider it in its analysis.

-- 

-j

-- 
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] Will a pointer point to C.xxx be garbage collected by Go runtime？

2019-02-28 Thread Cholerae Hu 
Consider the following code:
```
package main

/*
struct B {
  int i;
};

struct A {
  int j;
  struct B b;
};
*/
import "C"

func NewA() *C.struct_A {
  return _A{
j: 1,
b: C.struct_B{
  i: 2,
},
  }
}

func main() {
  a := NewA()
}
```
Will 'a' be scanned by go runtime? It is allocate by go runtime.

However, if a pointer point to C.xxx will be scanned, consider the 
following code:
```
package main

// #include 
import "C"
import (
  "runtime"
  "unsafe"
)

func main() {
  p := (*C.int)(C.malloc(8))
  C.free(unsafe.Pointer(p))
  runtime.GC()
}
```
If p is scanned, go runtime should throw a 'bad pointer' error, because the 
memory pointed by p is allocated by C.malloc, not go runtime.

-- 
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] I found a very strange code that would cause deadlocks and blocking，why???

2019-02-28 Thread Robert Engels 
I think it would be helpful if you learned more about concurrent programming. 
It is 10x harder, even with the simplifications that Go offers. If you don’t 
understand the concepts you are going to struggle. Start with some tutorials 
and work your way up. 

> On Feb 28, 2019, at 10:14 PM, mountain...@gmail.com wrote:
> 
> This is the stack information printed when blocking, how to see which G 
> blocking program?
> 
> SIGABRT: abort
> PC=0x7fff9ceabbf2 m=0 sigcode=0
> 
> goroutine 0 [idle]:
> runtime.pthread_cond_wait(0x1967620, 0x19675e0, 0x7fff)
> /usr/local/go/src/runtime/sys_darwin.go:302 +0x51
> runtime.semasleep(0x, 0x7fff5fbff670)
> /usr/local/go/src/runtime/os_darwin.go:63 +0x85
> runtime.notesleep(0x19673e0)
> /usr/local/go/src/runtime/lock_sema.go:167 +0xe3
> runtime.stoplockedm()
> /usr/local/go/src/runtime/proc.go:2165 +0x8a
> runtime.schedule()
> /usr/local/go/src/runtime/proc.go:2565 +0x2d9
> runtime.park_m(0xc72480)
> /usr/local/go/src/runtime/proc.go:2676 +0xae
> runtime.mcall(0x105722b)
> /usr/local/go/src/runtime/asm_amd64.s:299 +0x5b
> 
> goroutine 1 [semacquire]:
> sync.runtime_Semacquire(0xc27794)
> /usr/local/go/src/runtime/sema.go:56 +0x39
> sync.(*WaitGroup).Wait(0xc27794)
> /usr/local/go/src/sync/waitgroup.go:130 +0x64
> cmd/go/internal/work.(*Builder).Do(0xc00023b0e0, 0xc0003ee3c0)
> /usr/local/go/src/cmd/go/internal/work/exec.go:174 +0x38e
> cmd/go/internal/run.runRun(0x195c300, 0xc1e0e0, 0x1, 0x1)
> /usr/local/go/src/cmd/go/internal/run/run.go:137 +0x55b
> main.main()
> /usr/local/go/src/cmd/go/main.go:219 +0x7d4
> 
> goroutine 5 [syscall]:
> os/signal.signal_recv(0x0)
> /usr/local/go/src/runtime/sigqueue.go:139 +0x9f
> os/signal.loop()
> /usr/local/go/src/os/signal/signal_unix.go:23 +0x22
> created by os/signal.init.0
> /usr/local/go/src/os/signal/signal_unix.go:29 +0x41
> 
> goroutine 50 [select]:
> cmd/go/internal/work.(*Builder).Do.func2(0xc27794, 0xc00023b0e0, 
> 0xc0004b0620)
> /usr/local/go/src/cmd/go/internal/work/exec.go:155 +0x12f
> created by cmd/go/internal/work.(*Builder).Do
> /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x36a
> 
> goroutine 51 [select]:
> cmd/go/internal/work.(*Builder).Do.func2(0xc27794, 0xc00023b0e0, 
> 0xc0004b0620)
> /usr/local/go/src/cmd/go/internal/work/exec.go:155 +0x12f
> created by cmd/go/internal/work.(*Builder).Do
> /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x36a
> 
> goroutine 52 [syscall]:
> syscall.Syscall6(0x7, 0x12006, 0xc50c24, 0x0, 0xc0002f43f0, 0x0, 0x0, 
> 0xc0002f43f0, 0x0, 0xce2400)
> /usr/local/go/src/syscall/asm_darwin_amd64.s:41 +0x5
> syscall.wait4(0x12006, 0xc50c24, 0x0, 0xc0002f43f0, 0x90, 0x1566d60, 
> 0x14cc401)
> /usr/local/go/src/syscall/zsyscall_darwin_amd64.go:34 +0x7b
> syscall.Wait4(0x12006, 0xc50c74, 0x0, 0xc0002f43f0, 0x0, 0x1, 0x1)
> /usr/local/go/src/syscall/syscall_bsd.go:129 +0x51
> os.(*Process).wait(0xc0002fd4a0, 0xc34a00, 0xc50cf8, 0x0)
> /usr/local/go/src/os/exec_unix.go:38 +0x7b
> os.(*Process).Wait(0xc0002fd4a0, 0x15b89c8, 0x15b89d0, 0x15b89c0)
> /usr/local/go/src/os/exec.go:125 +0x2b
> os/exec.(*Cmd).Wait(0xc00052da20, 0x0, 0x0)
> /usr/local/go/src/os/exec/exec.go:465 +0x5b
> os/exec.(*Cmd).Run(0xc00052da20, 0x50, 0xcdf7c0)
> /usr/local/go/src/os/exec/exec.go:309 +0x5c
> cmd/go/internal/base.RunStdin(0xcdf7c0, 0x1, 0x1)
> /usr/local/go/src/cmd/go/internal/base/base.go:162 +0x11e
> cmd/go/internal/run.buildRunProgram(0xc00023b0e0, 0xc0003ee3c0, 0x13999b3, 
> 0xc00023b150)
> /usr/local/go/src/cmd/go/internal/run/run.go:151 +0x26d
> cmd/go/internal/work.(*Builder).Do.func1(0xc0003ee3c0)
> /usr/local/go/src/cmd/go/internal/work/exec.go:107 +0x72
> cmd/go/internal/work.(*Builder).Do.func2(0xc27794, 0xc00023b0e0, 
> 0xc0004b0620)
> /usr/local/go/src/cmd/go/internal/work/exec.go:165 +0xbb
> created by cmd/go/internal/work.(*Builder).Do
> /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x36a
> 
> goroutine 53 [select]:
> cmd/go/internal/work.(*Builder).Do.func2(0xc27794, 0xc00023b0e0, 
> 0xc0004b0620)
> /usr/local/go/src/cmd/go/internal/work/exec.go:155 +0x12f
> created by cmd/go/internal/work.(*Builder).Do
> /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x36a
> 
> goroutine 24 [chan receive]:
> cmd/go/internal/base.processSignals.func1(0xc86f00)
> /usr/local/go/src/cmd/go/internal/base/signal.go:21 +0x34
> created by cmd/go/internal/base.processSignals
> /usr/local/go/src/cmd/go/internal/base/signal.go:20 +0x93
> 
> rax0x104
> rbx0xea00
> rcx0x7fff5fbff488
> rdx0xea00
> rdi0x1967620
> rsi0xea01eb00
> rbp0x7fff5fbff520
> rsp0x7fff5fbff488
> r8 0x0
> r9 0x60
> r100x0
>

Re: [go-nuts] Is Go a single pass compiler?

2019-02-28 Thread David Riley 
Was this book written in the '70s or '80s?

Single-pass compilation is great in some ways (memory and time efficient), not 
in others (usability).  C is (sort of) single-pass (if you don't count the 
preprocessor, optimization passes, etc), which is why you need function 
prototypes.  Assemblers are very often single-pass.  C is basically a 
user-friendly front-end to the assembler anyway, so.

Languages built for the the minicomputers of the '70s and microcomputers of the 
'80s should be designed for a single pass, because if you were trying to do 
anything bigger than that it would likely take forever or exceed your available 
resources.  I don't think that has been a valid constraint on anything for a 
long time unless you're planning on e.g. compiling something on an AVR (for 
example, Forth is a single-pass language if you squint at it hard enough, and 
it fits nicely on some REALLY small things).


- Dave


> On Feb 27, 2019, at 6:46 PM, ivan.medoe...@gmail.com wrote:
> 
> Thanks, Ian.
> 
> I remember reading in some compiler book that languages should be designed 
> for a single pass to reduce compilation speed.
> 
> Go proves that wrong :) It's amazingly fast, looks like computers are pretty 
> good at traversing AST trees.

-- 
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] I found a very strange code that would cause deadlocks and blocking，why???

2019-02-28 Thread mountainfpf 
This is the stack information printed when blocking, how to see which G 
blocking program?

SIGABRT: abort
PC=0x7fff9ceabbf2 m=0 sigcode=0

goroutine 0 [idle]:
runtime.pthread_cond_wait(0x1967620, 0x19675e0, 0x7fff)
/usr/local/go/src/runtime/sys_darwin.go:302 +0x51
runtime.semasleep(0x, 0x7fff5fbff670)
/usr/local/go/src/runtime/os_darwin.go:63 +0x85
runtime.notesleep(0x19673e0)
/usr/local/go/src/runtime/lock_sema.go:167 +0xe3
runtime.stoplockedm()
/usr/local/go/src/runtime/proc.go:2165 +0x8a
runtime.schedule()
/usr/local/go/src/runtime/proc.go:2565 +0x2d9
runtime.park_m(0xc72480)
/usr/local/go/src/runtime/proc.go:2676 +0xae
runtime.mcall(0x105722b)
/usr/local/go/src/runtime/asm_amd64.s:299 +0x5b

goroutine 1 [semacquire]:
sync.runtime_Semacquire(0xc27794)
/usr/local/go/src/runtime/sema.go:56 +0x39
sync.(*WaitGroup).Wait(0xc27794)
/usr/local/go/src/sync/waitgroup.go:130 +0x64
cmd/go/internal/work.(*Builder).Do(0xc00023b0e0, 0xc0003ee3c0)
/usr/local/go/src/cmd/go/internal/work/exec.go:174 +0x38e
cmd/go/internal/run.runRun(0x195c300, 0xc1e0e0, 0x1, 0x1)
/usr/local/go/src/cmd/go/internal/run/run.go:137 +0x55b
main.main()
/usr/local/go/src/cmd/go/main.go:219 +0x7d4

goroutine 5 [syscall]:
os/signal.signal_recv(0x0)
/usr/local/go/src/runtime/sigqueue.go:139 +0x9f
os/signal.loop()
/usr/local/go/src/os/signal/signal_unix.go:23 +0x22
created by os/signal.init.0
/usr/local/go/src/os/signal/signal_unix.go:29 +0x41

goroutine 50 [select]:
cmd/go/internal/work.(*Builder).Do.func2(0xc27794, 0xc00023b0e0, 
0xc0004b0620)
/usr/local/go/src/cmd/go/internal/work/exec.go:155 +0x12f
created by cmd/go/internal/work.(*Builder).Do
/usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x36a

goroutine 51 [select]:
cmd/go/internal/work.(*Builder).Do.func2(0xc27794, 0xc00023b0e0, 
0xc0004b0620)
/usr/local/go/src/cmd/go/internal/work/exec.go:155 +0x12f
created by cmd/go/internal/work.(*Builder).Do
/usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x36a

goroutine 52 [syscall]:
syscall.Syscall6(0x7, 0x12006, 0xc50c24, 0x0, 0xc0002f43f0, 0x0, 0x0, 
0xc0002f43f0, 0x0, 0xce2400)
/usr/local/go/src/syscall/asm_darwin_amd64.s:41 +0x5
syscall.wait4(0x12006, 0xc50c24, 0x0, 0xc0002f43f0, 0x90, 0x1566d60, 
0x14cc401)
/usr/local/go/src/syscall/zsyscall_darwin_amd64.go:34 +0x7b
syscall.Wait4(0x12006, 0xc50c74, 0x0, 0xc0002f43f0, 0x0, 0x1, 0x1)
/usr/local/go/src/syscall/syscall_bsd.go:129 +0x51
os.(*Process).wait(0xc0002fd4a0, 0xc34a00, 0xc50cf8, 0x0)
/usr/local/go/src/os/exec_unix.go:38 +0x7b
os.(*Process).Wait(0xc0002fd4a0, 0x15b89c8, 0x15b89d0, 0x15b89c0)
/usr/local/go/src/os/exec.go:125 +0x2b
os/exec.(*Cmd).Wait(0xc00052da20, 0x0, 0x0)
/usr/local/go/src/os/exec/exec.go:465 +0x5b
os/exec.(*Cmd).Run(0xc00052da20, 0x50, 0xcdf7c0)
/usr/local/go/src/os/exec/exec.go:309 +0x5c
cmd/go/internal/base.RunStdin(0xcdf7c0, 0x1, 0x1)
/usr/local/go/src/cmd/go/internal/base/base.go:162 +0x11e
cmd/go/internal/run.buildRunProgram(0xc00023b0e0, 0xc0003ee3c0, 0x13999b3, 
0xc00023b150)
/usr/local/go/src/cmd/go/internal/run/run.go:151 +0x26d
cmd/go/internal/work.(*Builder).Do.func1(0xc0003ee3c0)
/usr/local/go/src/cmd/go/internal/work/exec.go:107 +0x72
cmd/go/internal/work.(*Builder).Do.func2(0xc27794, 0xc00023b0e0, 
0xc0004b0620)
/usr/local/go/src/cmd/go/internal/work/exec.go:165 +0xbb
created by cmd/go/internal/work.(*Builder).Do
/usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x36a

goroutine 53 [select]:
cmd/go/internal/work.(*Builder).Do.func2(0xc27794, 0xc00023b0e0, 
0xc0004b0620)
/usr/local/go/src/cmd/go/internal/work/exec.go:155 +0x12f
created by cmd/go/internal/work.(*Builder).Do
/usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x36a

goroutine 24 [chan receive]:
cmd/go/internal/base.processSignals.func1(0xc86f00)
/usr/local/go/src/cmd/go/internal/base/signal.go:21 +0x34
created by cmd/go/internal/base.processSignals
/usr/local/go/src/cmd/go/internal/base/signal.go:20 +0x93

rax0x104
rbx0xea00
rcx0x7fff5fbff488
rdx0xea00
rdi0x1967620
rsi0xea01eb00
rbp0x7fff5fbff520
rsp0x7fff5fbff488
r8 0x0
r9 0x60
r100x0
r110x202
r120x1967620
r130x16
r140x1
r150x7fffa5c9d3c0
rip0x7fff9ceabbf2
rflags 0x203
cs 0x7
fs 0x0
gs 0x0

在 2019年2月28日星期四 UTC+8下午8:44:55，Sameer Ajmani写道：
>
> The deadlock happens because the channel is empty, so the receive 
> operation blocks forever.
>
> The second version imports a package that may start new goroutines in its 
> init functions. If so, those goroutines may not be deadlocked, but the main 
> function is still blocked on the receive operation.
>
> It can be useful to send SIGQUIT to a

Re: [go-nuts] Re: I found a very strange code that would cause deadlocks and blocking，why???

2019-02-28 Thread Robert Engels 
It does not. 

> On Feb 28, 2019, at 9:13 PM, mountain...@gmail.com wrote:
> 
> First of all, I am very grateful for your reply. I still want to know if it 
> has anything to do with STW？
> 
> 在 2019年3月1日星期五 UTC+8上午3:55:57，Louki Sumirniy写道：
>> 
>> Channels require goroutines. `<-variable` blocks the goroutine it  is in and 
>> waits for another goroutine to do the opposite, being `channel <- value` You 
>> can't use channels without goroutines, and really, the main purpose for 
>> goroutines is exactly about moving things through channels.
>> 
>> Goroutines probably are the most confusing and error prone part of Go, as it 
>> can be very hard to see who is loading the channel and who is not, and if 
>> they are in the same goroutine it won't work, as one part of it waits for 
>> the other part that will never start running, because it already is, and is 
>> blocked.
> 
> -- 
> 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.

-- 
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] Re: I found a very strange code that would cause deadlocks and blocking，why???

2019-02-28 Thread Kurtis Rader 
On Thu, Feb 28, 2019 at 7:13 PM  wrote:

> First of all, I am very grateful for your reply. I still want to know if
> it has anything to do with STW？
>

What is "STW"? This is the first time that acronym has appeared in this
thread. If you're referring to "stop the world" garbage collection the
answer is "no" in as much as this behavior has nothing directly to do with
garbage collection.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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: I found a very strange code that would cause deadlocks and blocking，why???

2019-02-28 Thread mountainfpf 
First of all, I am very grateful for your reply. I still want to know if it 
has anything to do with STW？

在 2019年3月1日星期五 UTC+8上午3:55:57，Louki Sumirniy写道：
>
> Channels require goroutines. `<-variable` blocks the goroutine it  is in 
> and waits for another goroutine to do the opposite, being `channel <- 
> value` You can't use channels without goroutines, and really, the main 
> purpose for goroutines is exactly about moving things through channels.
>
> Goroutines probably are the most confusing and error prone part of Go, as 
> it can be very hard to see who is loading the channel and who is not, and 
> if they are in the same goroutine it won't work, as one part of it waits 
> for the other part that will never start running, because it already is, 
> and is blocked.
>

-- 
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: processing complex csv

2019-02-28 Thread Ahsan Deliri 
Thank you for the idea. 
Sometimes you just need someone to state the obvious. 

On Thursday, February 28, 2019 at 6:36:50 PM UTC-5, Mandolyte wrote:
>
> Something like this?
> - Create a map of the "wanted" struct using the employee ID as the key for 
> each
> - make the metrics maps too with date as the key. Be sure to use a 
> consistent format if a string, such as -MM-DD.
> - as you range over the rows and insert or update the struct
>
> Then range of the final/updated map to output the report or whatever you 
> want out of it.
>
> Cheers!
>
> On Thursday, February 28, 2019 at 4:48:34 PM UTC-5, Ahsan Deliri wrote:
>>
>> Hey gophers,
>>
>> So the problem is every week we get a new CSV file. 
>> It's got the same data sets for people, but also adds employees newly 
>> enrolled in the training program.
>> The CSV file just gets bigger because new data for this week is added but 
>> sometimes, error corrections are made for metrics from previous weeks that 
>> were incorrect.
>>
>> Example data from the CSV file:
>>
>> Week 
>> ,EmployeeID,AgentName,StaffGroup,TrainingStartDate,TrainingEndDate,TrainingStatus,CallsTaken,MetricA,MetricB,MetricC,SiteName
>>
>> 2019-02-04,12029065, Alex 
>> Bin,MNCCBEHR,2019-01-14,2019-01-27,1,0,0,0,0,naples
>>
>> 2019-02-04,12319346, Adam 
>> Ban,MNCCBEHR,2019-01-14,2019-01-27,1,114,49,701.44,0.48,new york
>>
>> 2019-02-09,12029065, Alex 
>> Bin,MNCCBEHR,2019-01-14,2019-01-27,1,100,80,90,64,naples
>>
>> 2019-02-09,12319346, Adam 
>> Ban,MNCCBEHR,2019-01-14,2019-01-27,1,114,49,70.44,37,new york
>>
>> 2019-02-14,12029065, Alex 
>> Bin,MNCCBEHR,2019-01-14,2019-01-27,1,40,60,30,1000,naples
>>
>> 2019-02-14,12319346, Adam 
>> Ban,MNCCBEHR,2019-01-14,2019-01-27,1,114,48,701.44,487,new york
>>
>> 2019-02-24,12029065, Alex 
>> Bin,MNCCBEHR,2019-01-14,2019-01-27,1,40,450,230,1000,naples
>>
>> 2019-02-24,12319346, Adam 
>> Ban,MNCCBEHR,2019-01-14,2019-01-27,1,114,0.4,705,43,new york
>>
>>
>> I can read the files and create a struct containing the employee info but 
>> it's really not what I want.
>>
>> What I want to know how to do is, to range over the CSV data, and when it 
>> finds the employeeID for it group the scores for each of those metrics into 
>> a slice of that metric.
>> This week Joe might just be freshly enrolled into the training program 
>> and as such he only has data for 1 week.
>> This week Tim has data for the 19th week in a row. So his data needs to 
>> be combed through and cleaned up without creating various repeated structs 
>> of Tim.
>>
>>
>> type HaveEmployee struct {
>> Week  string
>> EmployeeIDstring
>> AgentName string
>> StaffGroupstring
>> TrainingStartDate string
>> TrainingEndDate   string
>> TrainingStatusstring
>> CallsTakenstring
>> MetricA   string
>> MetricB   string
>> MetricC   string
>> SiteName  string
>> SiteIDstring
>> }
>>
>> What I want to know how to get is
>>
>> type WantEmployee struct {
>> Week  string
>> EmployeeIDstring
>> AgentName string
>> StaffGroupstring
>> TrainingStartDate string
>> TrainingEndDate   string
>> TrainingStatusstring
>> CallsTakenstring
>> MetricA   []MetricA
>> MetricB   []MetricB
>> MetricC   []MetricC
>> SiteName  string
>> SiteIDstring
>> }
>>
>> type MetricA struct {
>> Date string
>> Value string
>> }
>>
>> type MetricB struct {
>> Date string
>> Value string
>> }
>>
>> type MetricC struct {
>> Date string
>> Value string
>> }
>>
>> Here's an example of the code on the playground, 
>> https://play.golang.org/p/B81B36h9yFH 
>>
>> Would it be smart to try and get the ideal data struct right out of the 
>> CSV or would it make more sense to wrangle with a slice of structs?
>> Thank you in advance for your time and help.
>>
>>
>>
>>

-- 
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: golang program use lots of memory

2019-02-28 Thread Inada Naoki 
https://golang.org/doc/go1.12#runtime

> On Linux, the runtime now uses MADV_FREE to release unused memory. This 
is more efficient but may result in higher reported RSS. The kernel will 
reclaim the unused data when it is needed. To revert to the Go 1.11 
behavior (MADV_DONTNEED), set the environment variable 
GODEBUG=madvdontneed=1.

-- 
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] processing complex csv

2019-02-28 Thread Ahsan Deliri 
Hey gophers,

So the problem is every week we get a new CSV file. 
It's got the same data sets for people, but also adds employees newly 
enrolled in the training program.
The CSV file just gets bigger because new data for this week is added but 
sometimes, error corrections are made for metrics from previous weeks that 
were incorrect.

Example data from the CSV file:

Week 
,EmployeeID,AgentName,StaffGroup,TrainingStartDate,TrainingEndDate,TrainingStatus,CallsTaken,MetricA,MetricB,MetricC,SiteName

2019-02-04,12029065 <2019-02-04,12019965>, Alex 
Bin,MNCCBEHR,2019-01-14,2019-01-27,1,0,0,0,0,naples

2019-02-04,12319346 <2019-02-04,12019246>, Adam 
Ban,MNCCBEHR,2019-01-14,2019-01-27,1,114,49,701.44,0.48,new york

2019-02-09,12029065 <2019-02-04,12019965>, Alex 
Bin,MNCCBEHR,2019-01-14,2019-01-27,1,100,80,90,64,naples

2019-02-09,12319346 <2019-02-04,12019246>, Adam 
Ban,MNCCBEHR,2019-01-14,2019-01-27,1,114,49,70.44,37,new york

2019-02-14,12029065 <2019-02-04,12019965>, Alex 
Bin,MNCCBEHR,2019-01-14,2019-01-27,1,40,60,30,1000,naples

2019-02-14,12319346 <2019-02-04,12019246>, Adam 
Ban,MNCCBEHR,2019-01-14,2019-01-27,1,114,48,701.44,487,new york

2019-02-24,12029065 <2019-02-04,12019965>, Alex 
Bin,MNCCBEHR,2019-01-14,2019-01-27,1,40,450,230,1000,naples

2019-02-24,12319346 <2019-02-04,12019246>, Adam 
Ban,MNCCBEHR,2019-01-14,2019-01-27,1,114,0.4,705,43,new york


I can read the files and create a struct containing the employee info but 
it's really not what I want.

What I want to know how to do is, to range over the CSV data, and when it 
finds the employeeID for it group the scores for each of those metrics into 
a slice of that metric.
This week Joe might just be freshly enrolled into the training program and 
as such he only has data for 1 week.
This week Tim has data for the 19th week in a row. So his data needs to be 
combed through and cleaned up without creating various repeated structs of 
Tim.


type HaveEmployee struct {
Week  string
EmployeeIDstring
AgentName string
StaffGroupstring
TrainingStartDate string
TrainingEndDate   string
TrainingStatusstring
CallsTakenstring
MetricA   string
MetricB   string
MetricC   string
SiteName  string
SiteIDstring
}

What I want to know how to get is

type WantEmployee struct {
Week  string
EmployeeIDstring
AgentName string
StaffGroupstring
TrainingStartDate string
TrainingEndDate   string
TrainingStatusstring
CallsTakenstring
MetricA   []MetricA
MetricB   []MetricB
MetricC   []MetricC
SiteName  string
SiteIDstring
}

type MetricA struct {
Date string
Value string
}

type MetricB struct {
Date string
Value string
}

type MetricC struct {
Date string
Value string
}

Here's an example of the code on the 
playground, https://play.golang.org/p/B81B36h9yFH 

Would it be smart to try and get the ideal data struct right out of the CSV 
or would it make more sense to wrangle with a slice of structs?
Thank you in advance for your time and help.



-- 
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: How can I try debug.SetMaxHeap?

2019-02-28 Thread 'David Chase' via golang-nuts 
I think you actually want this stack of CLs.
Despite Gerrit's predictions of doom, in fact they cherry-pick cleanly onto 
tip, and it builds, and passes tests:

git fetch https://go.googlesource.com/go refs/changes/90/66090/4 && git 
cherry-pick FETCH_HEAD
git fetch https://go.googlesource.com/go refs/changes/50/46750/6 && git 
cherry-pick FETCH_HEAD
git fetch https://go.googlesource.com/go refs/changes/91/66091/4 && git 
cherry-pick FETCH_HEAD
git fetch https://go.googlesource.com/go refs/changes/92/66092/4 && git 
cherry-pick FETCH_HEAD
git fetch https://go.googlesource.com/go refs/changes/51/46751/13 && git 
cherry-pick FETCH_HEAD
git fetch https://go.googlesource.com/go refs/changes/40/151540/5 && git 
cherry-pick FETCH_HEAD
git fetch https://go.googlesource.com/go refs/changes/17/156917/4 && git 
cherry-pick FETCH_HEAD

The API will change, don't get too attached to it.




On Wednesday, February 20, 2019 at 2:12:01 PM UTC-5, Vinicius Fortuna wrote:
>
> My team is struggling with limiting the head size of a Go application and 
> would like to know how to use SetMaxHeap.
>
> We wrote a VpnExtension for iOS which gets killed by the OS if is consumes 
> more than 15MB, but there's no way to tell Go to not pass that limit. I 
> learned about the debug.SetMaxHeap experiment, and it seems that may solve 
> our problem. I'm ok running a custom runtime for now. 
> However, it's unclear how I can use it. it seems to be one a CL that was 
> never submitted and now has merge conflicts: 
> https://go-review.googlesource.com/c/go/+/46751
> How can I get a Go version with SetMaxHeap?
>
> Thanks
>
> Vinicius Fortuna
>
>
>

-- 
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] Is Go a single pass compiler?

2019-02-28 Thread Jim Ancona 
The first computer I ever programmed[1] had a Fortran compiler that stored
its intermediate representation on paper tape. As you might imagine, the
number of passes affected compilation speed a lot. I don't do compilers,
but I suspect that other bottlenecks matter much more today.

Jim

[1] - https://en.wikipedia.org/wiki/Monrobot_XI

On Wed, Feb 27, 2019 at 6:46 PM  wrote:

> Thanks, Ian.
>
> I remember reading in some compiler book that languages should be designed
> for a single pass to reduce compilation speed.
>
> Go proves that wrong :) It's amazingly fast, looks like computers are
> pretty good at traversing AST trees.
>
> On Wednesday, February 27, 2019 at 11:50:05 PM UTC+1, Ian Lance Taylor
> wrote:
>>
>> On Wed, Feb 27, 2019 at 2:42 PM  wrote:
>> >
>> > In Go functions can be used before they are defined, but as I
>> understand, it's still possible to have a single pass compiler.
>>
>> I don't think it's possible to compile Go in a single pass compiler,
>> unless you consider a separate parsing and code generation step to be
>> a single pass compiler.  In the general case, you can't generate code
>> for any Go function until you've seen all the functions in the
>> package.
>>
>> There are multiple Go compilers.  All the ones I am aware of are have
>> many passes.
>>
>> 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.
>

-- 
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: Performance comparison of Go, C++, and Java for biological sequencing tool

2019-02-28 Thread Louki Sumirniy 
It shouldn't really be surprising. Go and Java share the use of interfaces, 
but Go's concurrency is far lighter weight, and on top, Java has the extra 
burden of a virtual machine before it actually hits the CPU as binary code. 
I suspect also that the Go version could handle a much greater level of 
concurrency and then the advantage of compilation would be more visible.

On Thursday, 28 February 2019 18:05:55 UTC+1, Isaac Gouy wrote:
>
> "We reimplemented elPrep in all three languages and benchmarked their 
> runtime performance and memory use. Results: *The Go implementation 
> performs best*, yielding the best balance between runtime performance and 
> memory use. While the Java benchmarks report a somewhat faster runtime than 
> the Go benchmarks, the memory use of the Java runs is significantly higher."
>
> proggit discussion 
> 
>
> article 
>
>
>

-- 
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] CGO on Windows and Application Verifier

2019-02-28 Thread pierre . franco 
Hello everyone,

I wanted to know whether the issue of Application Verifier ( 
https://docs.microsoft.com/en-us/windows/desktop/win7appqual/application-verifier
 
) crashing when used on a C (or C++) program linked with a CGO-generated 
DLL.
This happens with Golang 1.11.4 and 1.11.5 for sure.

The repro is the following (needs a Windows with MingW-w64 installed and in 
the PATH):

1) Have this file in a folder with the name "main.go":
package main

import "C"
import "fmt"

//export test
func test(str *C.char) int64 {
fmt.Print(C.GoString(str))
return 42
}

func main() {
}


2) Execute "go build -buildmode=c-shared -o test.dll"

3) Create the following file in the same older folder with the name 
"main.c":
#include 

#include "test.h"

int main() {
printf("%lld", test("Foo\n"));
return 0;
}

4) Run "gcc -g test.dll main.c -o test.exe"
5) In Application Verifier, enable the "Basics" category for the test.exe 
executable
6) Start "gdb test.exe" and run the program
7) Boom

I suspect the "_rt0_amd64_windows_lib" routine (written in Go ASM, in 
src/runtime/rt0_windows_amd64.s in Golang's sources) to do some nasty stuff 
from a Windows ABI point-of-view (it looks correct from what I could 
understand when reading it though).
Then Application Verifier tries to walk the stack from some low-level heap 
allocation function, and crashes doing so.

Hoping someone here might have som insight for me,
Thanks,

Pierre FRANCO

-- 
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] Performance comparison of Go, C++, and Java for biological sequencing tool

2019-02-28 Thread 'Isaac Gouy' via golang-nuts 
"We reimplemented elPrep in all three languages and benchmarked their 
runtime performance and memory use. Results: *The Go implementation 
performs best*, yielding the best balance between runtime performance and 
memory use. While the Java benchmarks report a somewhat faster runtime than 
the Go benchmarks, the memory use of the Java runs is significantly higher."

proggit discussion 


article 


-- 
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] I found a very strange code that would cause deadlocks and blocking，why???

2019-02-28 Thread howardcshaw 
Sameer is correct, but to be clear - The *block* happens because the 
channel is empty, so the receive operation blocks forever. This happens in 
both of the cases you show.

The *deadlock* happens because *all* goroutines are blocked and none can 
continue. So if you start some other goroutine that is not blocked, you 
won't have a deadlock, even though your main routine is blocked forever, 
which you are inadvertently doing by that import. Or, more to the point, 
you have a deadlock that Go can't detect as such - because technically, 
there is a goroutine running that could at some point read from that 
channel and your main routine would be unblocked and continue. It won't, 
because it has no reference to it, but the compiler is not currently able 
to detect that.

Again, both cases actually block. It is merely that in the first case the 
compiler can detect that it is a 'forever-blocked' situation and kills the 
program with a warning that it was deadlocked.

Howard

-- 
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] net/http: expose dialing + writing errors from net package

2019-02-28 Thread Jérôme LAFORGE 
Hello Gophers,

(I have already asked this question at 
https://github.com/golang/go/issues/14203#issuecomment-467785036)

I want to know whether the error on http.Get("http://some.where;) is 
produced before or after httpclient sent the request (e.g. during tcp dial, 
tls or write request body in socket). I have defined this function.

func AfterRequestSent(err error) bool {
urlErr, ok := err.(*url.Error)
if !ok {
return true
}

opErr, ok := urlErr.Err.(*net.OpError)
if !ok {
return true
}

return opErr.Op != "dial" && opErr.Op != "write"
}

According to you, is it correct one? (e.g. no missing Op)

Thx in adv
regards

Jérôme

-- 
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] I found a very strange code that would cause deadlocks and blocking，why???

2019-02-28 Thread Sameer Ajmani 
The deadlock happens because the channel is empty, so the receive operation
blocks forever.

The second version imports a package that may start new goroutines in its
init functions. If so, those goroutines may not be deadlocked, but the main
function is still blocked on the receive operation.

It can be useful to send SIGQUIT to a blocked Go program to dump the
goroutine stack traces to the terminal.

S

On Thu, Feb 28, 2019 at 4:19 AM  wrote:

> dead lock：
>
> package main
>
> import (
> "fmt"
> // _ "github.com/go-sql-driver/mysql"
> )
>
> func main() {
> c1 := make(chan int, 10)
> fmt.Println(<-c1)
> }
>
>
> block：
>
> package main
>
> import (
> "fmt"
>
> _ "github.com/go-sql-driver/mysql"
> )
>
> func main() {
> c1 := make(chan int, 10)
> fmt.Println(<-c1)
> }
>
> --
> 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.
>

-- 
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] I found a very strange code that would cause deadlocks and blocking，why???

2019-02-28 Thread mountainfpf 
ok， thanks！

在 2019年2月28日星期四 UTC+8下午5:49:48，Jan Mercl写道：
>
> On Thu, Feb 28, 2019 at 10:20 AM > wrote:
>
> Please do not post colorized source code, particularly not using low 
> contrast, inverted color schemes. There are people not able to read it. 
> Some others may just ignore it or even consider it bad netiquette.
>
> Black on white is the most universally readable option. Thanks.
>
> -- 
>
> -j
>

-- 
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] I found a very strange code that would cause deadlocks and blocking，why???

2019-02-28 Thread Jan Mercl 
On Thu, Feb 28, 2019 at 10:20 AM  wrote:

Please do not post colorized source code, particularly not using low
contrast, inverted color schemes. There are people not able to read it.
Some others may just ignore it or even consider it bad netiquette.

Black on white is the most universally readable option. Thanks.

-- 

-j

-- 
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] I found a very strange code that would cause deadlocks and blocking，why???

2019-02-28 Thread mountainfpf 
dead lock：

package main

import (
"fmt"
// _ "github.com/go-sql-driver/mysql"
)

func main() {
c1 := make(chan int, 10)
fmt.Println(<-c1)
}


block：

package main

import (
"fmt"

_ "github.com/go-sql-driver/mysql"
)

func main() {
c1 := make(chan int, 10)
fmt.Println(<-c1)
}

-- 
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.