I actually thought about it and your way is strictly better, as it supports
CAS (if all interface types involved do), which the pointer-method doesn't.
On Tue, Nov 16, 2021 at 5:16 PM Stephen Illingworth <
stephen.illingwo...@gmail.com> wrote:
>
> How about just a 'container' type for the
> How about just a 'container' type for the interface.
>>
>> https://play.golang.org/p/WSXVjVHj1Ya
>>
>
>> For what I need, that does the job nicely. The type being stored in the
>> atomic.Value isn't changing so it satisfies the atomic.Value constraints
>> but I have the flexibility of the
On Tue, Nov 16, 2021 at 3:33 PM Stephen Illingworth <
stephen.illingwo...@gmail.com> wrote:
> How about just a 'container' type for the interface.
>
> https://play.golang.org/p/WSXVjVHj1Ya
>
> For what I need, that does the job nicely. The type being stored in the
> atomic.Value isn't changing
> I've found that the way around this is to create a new instance of
>> atomic.Value whenever I have reason to believe that the type to be stored
>> has changed.
>>
>
> That seems to be counter to the idea behind `atomic.Value`. Creating and
> setting the new `atomic.Value` requires
On Tue, Nov 16, 2021 at 1:25 PM Stephen Illingworth <
stephen.illingwo...@gmail.com> wrote:
> I've found that the way around this is to create a new instance of
> atomic.Value whenever I have reason to believe that the type to be stored
> has changed.
>
That seems to be counter to the idea
I believe your code is broken. You need to use a lock when checking and making
the switch (see double locking problem) or there would be no need to use
atomics.
If you run it under the race detector I am guessing it will fail.
> On Nov 16, 2021, at 6:25 AM, Stephen Illingworth
> wrote:
>
When using atomic.Values it is important that the type being stored is
consistent. Trying to store a different type in an atomic.Value will cause
a panic
panic: sync/atomic: store of inconsistently typed value into Value
I've found that the way around this is to create a new instance of
