Re: [go-nuts] Improving safe global variables with generic or inheritance

09:44 UTC+1 yan.z...@gmail.com wrote: > -- Forwarded message - > From: Zhaoxun Yan > Date: Mon, May 23, 2022 at 6:05 PM > Subject: Re: [go-nuts] Improving safe global variables with generic or > inheritance > To: Brian Candler > > *That's really essential. For example,

Fwd: [go-nuts] Improving safe global variables with generic or inheritance

-- Forwarded message - From: Zhaoxun Yan Date: Mon, May 23, 2022 at 6:05 PM Subject: Re: [go-nuts] Improving safe global variables with generic or inheritance To: Brian Candler *That's really essential. For example, using your library, the following code is most definitely

Re: [go-nuts] Improving safe global variables with generic or inheritance

It would be helpful if you could link to actual code, preferably on the playground. That error message seems to indicate that you are not using gotip. I got mixed up earlier, when I wrote Go 1.18. I meant Go 1.19, the next Go version. On Mon, May 23, 2022 at 11:51 AM Zhaoxun Yan wrote: > `&` won

Re: [go-nuts] Improving safe global variables with generic or inheritance

`&` won't make any difference: undefined: atomic.Int32 On Mon, May 23, 2022 at 4:31 PM Axel Wagner wrote: > On Mon, May 23, 2022 at 10:19 AM Zhaoxun Yan > wrote: > >> Yes but the syntax is confusing, e.g. the code below fails: >> > > That's because you can't take the address of a call expres

Re: [go-nuts] Improving safe global variables with generic or inheritance

You could add them as methods. But as I said, I don't think they are good APIs. I think the `Do` I described is the most reasonable compromise, if you really want a one-size-fits-all generic solution. Otherwise, use fine-grained locking or sync/atomic specific to your use-case. On Mon, May 23, 202

Re: [go-nuts] Improving safe global variables with generic or inheritance

type Locked[T any] struct { mu sync.Mutex val T } func (l *Locked[T]) Do(f func(T) T) { l.mu.Lock() defer l.mu.Unlock() l.val = f(l.val) } Could you elaborate how 'Save/Store' , 'Load' and 'Tick / Increase ' get applied to the code above? Thanks. On Mon, May 23, 2022 at 3:2

Re: [go-nuts] Improving safe global variables with generic or inheritance

On Mon, May 23, 2022 at 10:19 AM Zhaoxun Yan wrote: > Yes but the syntax is confusing, e.g. the code below fails: > That's because you can't take the address of a call expression. That is, your code is interpreted as &(a.Load()), while you might have intended (&a).Load()

Re: [go-nuts] Improving safe global variables with generic or inheritance

There are also some changes in there for Go 1.18, specifically the addition of some types, so that only atomic operations can be done: https://pkg.go.dev/sync/atomic@master Yes but the syntax is confusing, e.g. the code below fails: package main import ( "fmt" "sync/atomic" ) var a

Re: [go-nuts] Improving safe global variables with generic or inheritance

FWIW a compromise is to have type Locked[T any] struct { mu sync.Mutex val T } func (l *Locked[T]) Do(f func(T) T) { l.mu.Lock() defer l.mu.Unlock() l.val = f(l.val) } This forces modifications to be under the protection of a mutex while also allowing those modifications to d

Re: [go-nuts] Improving safe global variables with generic or inheritance

> It's best to be intentional about it and explicitly acquire and release a mutex around the critical sections of your code - because ultimately, only your code knows which sections are critical. That's really essential. For example, using your library, the following code is most definitely *n

Re: [go-nuts] Improving safe global variables with generic or inheritance

Just to be clear, are you aware of the sync/atomic package? https://pkg.go.dev/sync/atomic There are also some changes in there for Go 1.18, specifically the addition of some types, so that only atomic operations can be done: https://pkg.go.dev/sync/atomic@master I mention this because atomic.Value

[go-nuts] Improving safe global variables with generic or inheritance

Hi gophers! In the last post I proposed a way to avoid I/O race on any global variable: https://groups.google.com/g/golang-nuts/c/4AW1Ss9Tjp0 However, the code does not seem tidy, since each type needs to repeat defining the two methods Save and Load, though using this methods is easy. So I di