Re: [go-nuts] how cgo handle user define signal ? need go pass the signal handle to c

On Tue, Aug 13, 2019 at 1:03 AM hui zhang wrote: > > in other words > we need a go runtime signal mask . > just google, no such api provided by go yet . > I want know why ? > any workaround? All the details of signal handling in Go can be seen at https://golang.org/pkg/os/signal. There is no Go

Re: [go-nuts] Re: mutual exclusion algorithm of Dijkstra - strange behaviour

On Fri, Aug 16, 2019 at 9:24 PM wrote: > > Could you let me know which compiler can support pre-emption and how to > enable it? Thanks. No current Go toolchain supports preemption in all cases; for the gc toolchain, that is https://golang.org/issue/10958. But the exact definition of a busy

Re: [go-nuts] Re: mutual exclusion algorithm of Dijkstra - strange behaviour

Could you let me know which compiler can support pre-emption and how to enable it? Thanks. On Saturday, August 17, 2019 at 9:20:07 AM UTC+8, Ian Davis wrote: > > On Fri, 16 Aug 2019, at 7:09 PM, dr.ch...@gmail.com wrote: > > Dear Community and dear Go-developers, > > Meanwhile it is clear why

Re: [go-nuts] Re: mutual exclusion algorithm of Dijkstra - strange behaviour

On Fri, 16 Aug 2019, at 7:09 PM, dr.ch.mau...@gmail.com wrote: > Dear Community and dear Go-developers, > > Meanwhile it is clear why things do not work: > The Go-Scheduler is unable to allow to switch to another goroutine in > busy-waiting-loops - > the only possibility to get around that

[go-nuts] Re: Tips for reproducing flaky Go tests

I wish Go had a deterministic execution mode with predefined randomization seed. The to reproduce such test you would only need a single seed number. We built such system for testing our distributed application and it was very useful to track rare race conditions. On Thursday, August 15, 2019

Re: [go-nuts] Re: mutual exclusion algorithm of Dijkstra - strange behaviour

On Fri, Aug 16, 2019 at 8:09 PM wrote: > Meanwhile it is clear why things do not work: > The Go-Scheduler is unable to allow to switch to another goroutine in > busy-waiting-loops - > the only possibility to get around that problem is either to put > "switch-steps" into the source > - either

Re: [go-nuts] Re: mutual exclusion algorithm of Dijkstra - strange behaviour

Your code is incorrect for Go. You need to use correct concurrent code. It is documented that tight loops that do not involve function calls may not allow GC to occur. > On Aug 16, 2019, at 1:09 PM, dr.ch.mau...@gmail.com wrote: > > Dear Community and dear Go-developers, > > Meanwhile it is

[go-nuts] Re: mutual exclusion algorithm of Dijkstra - strange behaviour

Dear Community and dear Go-developers, Meanwhile it is clear why things do not work: The Go-Scheduler is unable to allow to switch to another goroutine in busy-waiting-loops - the only possibility to get around that problem is either to put "switch-steps" into the source - either

Re: [go-nuts] for i := range

One ranges a copy of the array, the other does not: https://play.golang.org/p/Z3InmyFqQN3 On Fri, Aug 16, 2019, 19:11 Vadim Maximov wrote: > Hi, all! > > Is *for.*..*range* over an address/reference of an array faster than > regular *for...range*? For instance: > > arr :=[...]int{1,2,3} > for

[go-nuts] for i := range

Hi, all! Is *for.*..*range* over an address/reference of an array faster than regular *for...range*? For instance: arr :=[...]int{1,2,3} for _,v := range { fmt.Println(v) } I heard that it is slightly faster for huge arrays, but why is it so? And is it actually true (or makes sense)? --

Re: [go-nuts] panic: interface conversion: interface is nil, not encoding.BinaryUnmarshaler

Hi Axel, Thanks a lot for looking into this. Your post makes things much clearer for me. In particular, I now think that I probably should not have (Un)MarshalBinary() methods on the interface type, but have them only on the concrete type instead. For example, this works:

[go-nuts] Re: All goroutines are parked during bgsweep() running. Is it a issue?

Hi, Please using `xz -d bgsweep.trace.xz ` decompress this file before running `go tool trace bgsweep.trace`. 在 2019年8月16日星期五 UTC+8下午5:19:03，gerald...@gmail.com写道： > > How about uploading the svg, so people

[go-nuts] Re: All goroutines are parked during bgsweep() running. Is it a issue?

How about uploading the svg, so people can zoom into? On Wednesday, August 14, 2019 at 11:34:58 AM UTC-4, nea...@gmail.com wrote: > > [image: issue.png] > > > 在 2019年8月14日星期三 UTC+8下午7:35:48，neal hu写道： >> >> Hi All >> >> I found my application has a strange issue by go trace. All goroutines >>

Re: [go-nuts] Re: What is the reason behind time.Parse using a reference time?

On Fri, 16 Aug 2019 at 01:24, Michael Baldry wrote: > I agree with that. It is an odd choice, as I've never seen any other > library use a reference date like that - there may be many but in 20 years, > I've not seen one. > > I think your argument about Parse is valid, but in most cases, you'll

Re: [go-nuts] Re: What is the reason behind time.Parse using a reference time?

On Thu, 15 Aug 2019 07:52:24 +0100 Michael Baldry wrote: > It's useful to remember the reference time has a pattern, > but the MST, 12 hour clock and it not being in a common order There is no such thing as "common order" of date/time notation. This notation is a part of the local culture. The