Re: [go-nuts] implementation of sync.atomic primitives

On Sun, Mar 18, 2018 at 9:47 PM, shivaram via golang-nuts wrote: > > I noticed that internally, the language implementation seems to rely on the > atomicity of reads to single-word values: > >

[go-nuts] implementation of sync.atomic primitives

I noticed that internally, the language implementation seems to rely on the atomicity of reads to single-word values: https://github.com/golang/go/blob/bd859439e72a0c48c64259f7de9f175aae3b9c37/src/runtime/chan.go#L160 As I understand it, this atomicity is provided by the cache coherence

[go-nuts] Re: My views on Go and why it's better than Scripting

> We argue that only experts should use scripting languages (scripts) for computer programming because beginners cannot understand how dangerous the flexibility of scripts can be. For example, the assignment of variables with the same name to different types is often a cause of

[go-nuts] Best practices for package maintainers

Hello everyone, I've opened up a google doc (previously a page on the wiki) to collect what are considered best practices for package maintainers: https://docs.google.com/document/d/1FJTnxs7LelXcq1ILmEiLxOwDmAQfbH_DWCy4-ZOFxYc/edit?usp=sharing. It was sparked originally by tweets from Mark

[go-nuts] Re: How to reuse go fix tool code

A minor side comment: On Sunday, March 18, 2018 at 12:47:11 PM UTC-4, thepud...@gmail.com wrote: > > > from golang/tools eg help via > https://github.com/golang/tools/blob/release-branch.go1.10/refactor/eg/eg.go#L20 > > Only refactorings that replace one expression with another, regardless > of

Re: [go-nuts] glr support in goyacc?

I believe Ian was saying he's not aware of anybody working on adding GLR support to goyacc. On Mon, Mar 12, 2018 at 1:23 AM David Wahlstedt < david.wahlstedt@gmail.com> wrote: > There are people working on it. This for instance: > https://github.com/chemikadze/asn1go > > Furthermore, if you

Re: [go-nuts] Re: [Advice needed] How to vendor common dependencies for plugins

Do you have to use plugins? I would avoid them whenever possible. What benefit do you expect to get from using them? On Sun, Mar 11, 2018 at 1:03 AM Jay Guo wrote: > Bump.. any thoughts? Thanks! > > - J > > > On Thursday, March 8, 2018 at 2:03:37 PM UTC+8, Jay Guo

Re: [go-nuts] Re: Would this race condition be considered a bug?

2018-03-18 10:27 GMT-07:00 Jan Mercl <0xj...@gmail.com>: > On Sun, Mar 18, 2018 at 6:21 PM Devon H. O'Dell > wrote: > >> * There is no way to force at least 16 byte alignment of data per the > language spec, so there is no way to implement DCAS (notably missing > from

Re: [go-nuts] Re: Would this race condition be considered a bug?

On Sun, Mar 18, 2018 at 6:21 PM Devon H. O'Dell wrote: > * There is no way to force at least 16 byte alignment of data per the language spec, so there is no way to implement DCAS (notably missing from sync/atomic) on amd64 (cmpxchg16b requires 16 byte alignment of its

Re: [go-nuts] Re: Would this race condition be considered a bug?

2018-03-18 9:34 GMT-07:00 Michael Jones : > Subtle observation--it is not fundamentally the memory model theorized in Go > or C++ specifications that causes this--rather it is the least strong > guarantee of the hardware on which these languages promise that standard >

[go-nuts] Re: How to reuse go fix tool code

Hi Anuj, Two quick comments. 1. FYI, in case you didn't see this in the recent vgo dependency management discussion, go fix might start to be used much more broadly in the not-too-distant future across the go community as a way to help automate in some cases the ability to update client code

Re: [go-nuts] Re: Would this race condition be considered a bug?

Subtle observation--it is not fundamentally the memory model theorized in Go or C++ specifications that causes this--rather it is the *least strong guarantee of the hardware *on which these languages promise that *standard programs will work as specified, *and following that, the decision of

Re: [go-nuts] Re: Would this race condition be considered a bug?

2018-03-18 1:42 GMT-07:00 David Anderson : > There's a difference though. The program that uses sync/atomic will behave > non-deterministically, but within a small set of possible outcomes. The one While a fair point, I'd also note the set of possible outcomes is not small and

Re: [go-nuts] Re: Would this race condition be considered a bug?

That post is fantastic and horrible at the same time. It is mandatory read for anyone endeavoring into concurrent programming however. On Sun, Mar 18, 2018, 09:42 David Anderson wrote: > There's a difference though. The program that uses sync/atomic will behave >

[go-nuts] Re: Long running task in select case

I came to the following solution for my long running tasks, using go-routines & the context package, https://play.golang.org/p/2V_29lHt4Wn package main import ( "context" "fmt" "time" ) //LongRunningTask func LongRunningTask(ctx context.Context, index int) (err error) { // we'll

Re: [go-nuts] Re: Would this race condition be considered a bug?

There's a difference though. The program that uses sync/atomic will behave non-deterministically, but within a small set of possible outcomes. The one without could do anything. In addition to producing an incorrect numeric result, it could deadlock, segfault, jump execution to some random place

Re: [go-nuts] Re: Would this race condition be considered a bug?

Perhaps better illustrated: package main import ( "fmt" "time" ) type info struct { count int idint } var stop int32 func runner(id int, c chan info) { info := info{id: id} for stop == 0 { info.count++

[go-nuts] Re: Would this race condition be considered a bug?

I'm considering only the case when there is a concurrent print of the context and also a concurrent context cancel. On Friday, March 16, 2018 at 5:16:27 AM UTC-4, Jérôme Champion wrote: > > Any race is a bug. When there is a race, the compiler is free to do > whatever it wants. > > What do you