On Sun, 27 Oct 2019 20:20:07 +
roger peppe wrote:
> If two things aren't writing concurrently to the same address, what's the
> problem?
I've got an impression that OP is concerned about arriving at
inconsistent/"impossible" shared state (due to poorly thought architecture).
30-20yrs ago th
You are absolutely right. Apologies.
On Mon, 2019-10-28 at 08:43 +, roger peppe wrote:
> On Sun, 27 Oct 2019, 21:31 Dan Kortschak, wrote:
>
> > This is not necessarily due to races. You can have this exact
> > situation
> > occurring in single threaded code. I don't think any mention of
> >
Yes, the issue is twofold.
Because everything is passed by "copy", it might feel safe to pass around
structs with slice fields, especially and perhaps unknowingly as "interior
fat pointers" in structs.
But, one should remember that these objects are always shallow copies in
the sense that map/
On Sun, 27 Oct 2019, 21:31 Dan Kortschak, wrote:
> This is not necessarily due to races. You can have this exact situation
> occurring in single threaded code. I don't think any mention of race
> issues was made here.
>
The thread subject mentions goroutines and the original message talks
specif
This is not necessarily due to races. You can have this exact situation
occurring in single threaded code. I don't think any mention of race
issues was made here.
On Sun, 2019-10-27 at 08:53 +, roger peppe wrote:
> On Sun, 27 Oct 2019, 00:04 Gert, wrote:
>
> > I believe it's going to be to h
>> I think it only catches concurrent access to the same address, so not sure
>> if it catches everything.
>
>
> If two things aren't writing concurrently to the same address, what's the
> problem?
I took that to mean 'things may be updating concurrently at different
addresses inside an array ba
On Sun, 27 Oct 2019, 12:33 Gert, wrote:
>
> On Sunday, October 27, 2019 at 9:54:29 AM UTC+1, rog wrote:
>>
>>
>> On Sun, 27 Oct 2019, 00:04 Gert, wrote:
>>
>>> I believe it's going to be to hard to write a go vet analyser that could
>>> warn to detect unintended state change on a array from two
On Sunday, October 27, 2019 at 9:54:29 AM UTC+1, rog wrote:
>
>
> On Sun, 27 Oct 2019, 00:04 Gert, > wrote:
>
>> I believe it's going to be to hard to write a go vet analyser that could
>> warn to detect unintended state change on a array from two different
>> pointers.
>>
>
> Isn't that why we
On Sun, 27 Oct 2019, 00:04 Gert, wrote:
> I believe it's going to be to hard to write a go vet analyser that could
> warn to detect unintended state change on a array from two different
> pointers.
>
Isn't that why we have the race detector?
--
> You received this message because you are subsc
On Saturday, October 26, 2019 at 10:22:42 PM UTC+2, atd...@gmail.com wrote:
>
>
> On Saturday, October 26, 2019 at 9:47:39 PM UTC+2, Ian Lance Taylor wrote:
>>
>> On Sat, Oct 26, 2019 at 10:50 AM atd...@gmail.com
>> wrote:
>> >
>> > I get that we can do that but it's not strictly about slices o
On Saturday, October 26, 2019 at 9:47:39 PM UTC+2, Ian Lance Taylor wrote:
>
> On Sat, Oct 26, 2019 at 10:50 AM atd...@gmail.com > wrote:
> >
> > I get that we can do that but it's not strictly about slices operations
> such as appending or copying.
> > Of course, we could copy slices all th
On Sat, Oct 26, 2019 at 10:50 AM atd...@gmail.com wrote:
>
> I get that we can do that but it's not strictly about slices operations such
> as appending or copying.
> Of course, we could copy slices all the time but then there is no benefit in
> having them and it is not ergonomic as your exampl
12 matches
Mail list logo
