[go-nuts] Trying to understand HTTP connection pooling behaviour - new DNS lookup

[Amit Saha]

Hi, it seems that the http client automatically performs a DNS lookup when an 
existing connection is terminated by the server. I simulated it via changing 
the IP address in /etc/hosts.

Can someone point me to the code where this logic is checked?

I am looking at https://golang.org/src/net/http/transport.go 
 but haven’t found something yet 
- quite a beginner here.

Thanks,
Amit.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/748676D6-1E21-4E78-BF3C-87ADC0D8E0E2%40gmail.com.

[go-nuts] Give the zero time value a location, and it won't survive a roundtrip to JSON?

['Robert Ma' via golang-nuts]

Hi all,

Time is complicated.

Today I found myself in a rabbit hole. For some unrelated reason, I got a 
time value in a non-UTC location that's otherwise zero (IsZero=true). This 
value doesn't seem to survive a roundtrip to JSON. See this playground for 
a minimal reproduction: https://play.golang.org/p/QdglfKYkstS

Is this expected, a bug, or an undefined behaviour? I checked RFC 3339, 
which time uses as the JSON serialization format, and it seems to support 
AD to AD, but I have to admit I know little about time.

Cheers,
Robert

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/80962b1e-0b48-4bdb-ac04-f77ae63ccb00n%40googlegroups.com.

[go-nuts] Re: Give the zero time value a location, and it won't survive a roundtrip to JSON?

['Robert Ma' via golang-nuts]

Is this because the 2-second offset of LMT gets lost in RFC 3339
representation?

On Fri, Nov 27, 2020 at 6:33 PM Robert Ma  wrote:

> Hi all,
>
> Time is complicated.
>
> Today I found myself in a rabbit hole. For some unrelated reason, I got a
> time value in a non-UTC location that's otherwise zero (IsZero=true). This
> value doesn't seem to survive a roundtrip to JSON. See this playground for
> a minimal reproduction: https://play.golang.org/p/QdglfKYkstS
>
> Is this expected, a bug, or an undefined behaviour? I checked RFC 3339,
> which time uses as the JSON serialization format, and it seems to support
> AD to AD, but I have to admit I know little about time.
>
> Cheers,
> Robert
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOPAaN%2BWvZ73Z-oMVaGmDt-Gr5DEk7ZtQeU43x5fKrCFW42%3DqQ%40mail.gmail.com.

Re: [go-nuts] History & origins of the Go memory model

[Ian Lance Taylor]

On Fri, Nov 27, 2020 at 12:57 PM Daniel Fava  wrote:
>
> Does anyone know how the Go memory model came to be?  I don't have technical 
> questions about it.  I just would like to know the historical context.
>
> The model is specified in terms of happens-before, due to Lamport.  But the 
> following rule, which allows channels to be used as locks, was not part of 
> Lamport's original formulation:
>
> "A receive from an unbuffered channel happens before the send on that channel 
> completes. "
>
> I'm curious who (if anyone) was involved in including this rule.  How did it 
> come to be?
>
> I also find it fascinating how the word "completes" seems to make a world of 
> difference.  As I read it, removing the word "completes" from the rule above 
> (and from the rule connecting a sender and its corresponding receiver 
> receiver) would lead to a quite different memory model.  I'm curious how 
> intentional the "completes" is.

As I recall, Tom Szymanski asked for the rules about when one
goroutine would see changes made by another goroutine, and how that
related to channel operations.  Russ Cox described what he thought
should happen, Tom encouraged him to write that down, and Russ did,
winding up with
https://go.googlesource.com/go/+/82c38cf8dd628e6c90b6f1160be2a8d5088b77c9/doc/mem.html
(when reading that doc, remember that it was written in February,
2009, and that the syntax has changed since then).

The "completes" is intentional.  A send/receive on an unbuffered
channel was always intended to serve as a synchronization point
between the goroutines.  Otherwise it would be hard for different
goroutines to synchronize on anything.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXQcR7e0QU8rt4NbdLrqGtc92LzYPwWjyAs6u65C8dOUA%40mail.gmail.com.

[go-nuts] History & origins of the Go memory model

[Daniel Fava]

Hi,

Does anyone know how the Go memory model came to be?  I don't have 
technical questions about it.  I just would like to know the historical 
context.

The model is specified in terms of happens-before, due to Lamport.  But the 
following rule, which allows channels to be used as locks, was not part of 
Lamport's original formulation:

"A receive from an unbuffered channel happens before the send on that 
channel completes. "

I'm curious who (if anyone) was involved in including this rule.  How did 
it come to be?

I also find it fascinating how the word "completes" seems to make a world 
of difference.  As I read it, removing the word "completes" from the rule 
above (and from the rule connecting a sender and its corresponding receiver 
receiver) would lead to a quite different memory model.  I'm curious how 
intentional the "completes" is.

Thanks a lot!
Daniel

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ea5f6db9-229b-49c0-a970-7a964d60577en%40googlegroups.com.

Re: [go-nuts] concurrency safety

[Øyvind Teig]

Great! I liked Mill's lecture. After having seen it, here's my favourite:

*Clojure core.async*, lecture (45 mins). Rich Hickey discusses the 
motivation, design and use of the Clojure core.async library. He also talks 
about go. See https://www.infoq.com/presentations/clojure-core-async/ 
(lecture 22Nov2013) and 
https://clojure.org/news/2013/06/28/clojure-clore-async-channels 
(description).  Additionally you can download the soundtrack from this as 
an mp3.
Minutes into the lecture:
13.57 - CSP background
18.24 - The difference between blocking and parking. Also about IOC threads 
(Inversion of Control threads)
19.12 - The description of the difference between blocking and parking 

About *blocking*, I have a blog note myself: 
https://www.teigfam.net/oyvind/home/technology/092-not-so-blocking-after-all/ - 
Disclaimer : no 
money, ads, gifts in my blog notes. Only fun and expenses. 

fredag 27. november 2020 kl. 12:19:11 UTC+1 skrev b.ca...@pobox.com:

> On Friday, 27 November 2020 at 10:32:11 UTC oyvin...@teigfam.net wrote:
>
>> Thread safety, concurrency safety, goroutines safety. The same stuff to 
>> me.  
>>
>> It's important that concurrent goroutines don't interfere with each other 
>> in such a way that internal state is compromised by other goroutines. 
>> Typically through access to internal data, through pointers.
>>
>
> Not just that, but also:
>
> -  any global variables.  Even reading an 'int' while some other goroutine 
> is updating it is unsafe; it may give undefined behavior.
>
> - concurrent read and write accesses to the same map or slice can cause 
> the program to panic.  Note that map and slice values contain hidden 
> pointers inside them.  So if two goroutines have the same map or slice 
> value, they are aliasing to the same underlying data.
>
> These can trip up people used to (say) Python, where such accesses are 
> atomic - primarily because of Python's Global Interpreter Lock.
>
> (There is sync.Map  which is 
> concurrency-safe, but if you need this, there's probably a better solution 
> in your architecture)
>  
>
>> If only go channels are used to communicate between goroutines, than that 
>> case is closed. That's one of the reasons they exist - also in other 
>> similar languages, with that aspect often based on CSP.
>>
>
> Here's a video explaining how channels can replace various concurrency 
> primitives: it's worth getting your head around.
> https://www.youtube.com/watch?v=5zXAHh5tJqQ
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5d850534-af12-4820-994b-e9eb728f2d5an%40googlegroups.com.

Re: [go-nuts] [generics] Separating type parameters, regular parameters, and return parameters

[Robert Engels]

This is best solved by syntax highlighting in an editor. Doesn’t do much for b 
& w printed training materials - but you can achieve similar results with bold 
/ font choice. 

> On Nov 27, 2020, at 9:49 AM, 'Axel Wagner' via golang-nuts 
>  wrote:
> 
> 
>> On Fri, Nov 27, 2020 at 3:42 PM Yaw Boakye  wrote:
> 
>> I disagree on accepting "that generic function signatures are inherently 
>> more crowded and less readable." I mean, inherently more crowded and less 
>> readable looks like something that one should apologize for (1) when 
>> teaching the language, and (2) submitting code for review. And in my 
>> experience teaching languages, some of these non-issues (to seasoned 
>> programmers) can be a real turn-off. If there's one reason people choose Go 
>> over, say, Rust, it is because of Go's readability. I honestly think it can 
>> get better, not worse. The code example I showed presents a readability 
>> challenge, and I'm not even new to Go.
> 
> I didn't say there isn't an issue, I said I think the issue is inherent and 
> thus unsolvable.
> I personally definitely don't believe it would be solved by adding a colon 
> between those parameter lists. If anything, I'd probably go back to the 
> previous incarnation of the design, where there was still a "type" keyword in 
> the type arguments, to make them stand out more.
>  
>> 
>> Yaw
>> 
>>> On Fri, Nov 27, 2020 at 2:27 PM Axel Wagner  
>>> wrote:
>>> 
>>> 
 On Fri, Nov 27, 2020 at 3:14 PM wher...@gmail.com  
 wrote:
 I'd like to propose that we separate the type and function parameters from 
 the return parameters with a colon
>>> 
>>> That would mean that either a) generic and non-generic functions would 
>>> differ by a : after the arguments, which seems confusing, or b) we could 
>>> allow non-generic functions to also have a :, but then we'd have two ways 
>>> to write them, which also seems confusing or c) we could require them to 
>>> have a :, which would break compatibility.
>>> 
>>> Personally, I don't like either of them. And perceive any readability 
>>> benefit to be very minor at best. I don't really see them as significantly 
>>> different at all.
>>> 
>>> I also feel that we already changed from `()` to `[]` and removed the 
>>> `type`, to help readability. I think at some point we're just going to have 
>>> to accept that generic function signatures are inherently more crowded and 
>>> less readable and stop hoping that adding more syntax will change that.
>>>  
 More importantly, while the editor highlighting will be a good thing (and 
 could greatly benefit from the presence of the colon), it doesn't become 
 strictly necessary.
>>> 
>>> It already isn't strictly necessary and it won't be with type-parameters 
>>> either.
>>> 
 
 
 Regards,
 Yaw
 -- 
 You received this message because you are subscribed to the Google Groups 
 "golang-nuts" group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to golang-nuts+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/golang-nuts/f67fe5d8-21a2-4b13-ab04-2935f092d727n%40googlegroups.com.
>> 
>> 
>> -- 
>> Curried programmer
>> Homepage: http://yawboakye.com
>> I'm tweeting when I'm not coding when I'm not holding my niece.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfH6BBBqZzUqzyfkMuEGoHtGq4tXdM%3DszEFUPq-QSKKXjQ%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/74BD5B09-82DF-4F88-8BCC-5C7850E29B9F%40ix.netcom.com.

Re: [go-nuts] [generics] Separating type parameters, regular parameters, and return parameters

['Axel Wagner' via golang-nuts]

On Fri, Nov 27, 2020 at 3:42 PM Yaw Boakye  wrote:

> I disagree on accepting "that generic function signatures are inherently
> more crowded and less readable." I mean, inherently more crowded and less
> readable looks like something that one should apologize for (1) when
> teaching the language, and (2) submitting code for review. And in my
> experience teaching languages, some of these non-issues (to seasoned
> programmers) can be a real turn-off. If there's one reason people choose Go
> over, say, Rust, it is because of Go's readability. I honestly think it can
> get better, not worse. The code example I showed presents a readability
> challenge, and I'm not even new to Go.
>

I didn't say there isn't an issue, I said I think the issue is inherent and
thus unsolvable.
I personally definitely don't believe it would be solved by adding a colon
between those parameter lists. If anything, I'd probably go back to the
previous incarnation of the design, where there was still a "type" keyword
in the type arguments, to make them stand out more.


>
> Yaw
>
> On Fri, Nov 27, 2020 at 2:27 PM Axel Wagner 
> wrote:
>
>>
>>
>> On Fri, Nov 27, 2020 at 3:14 PM wher...@gmail.com 
>> wrote:
>>
>>> I'd like to propose that we separate the type and function parameters
>>> from the return parameters with a colon
>>>
>>
>> That would mean that either a) generic and non-generic functions would
>> differ by a : after the arguments, which seems confusing, or b) we could
>> allow non-generic functions to also have a :, but then we'd have two ways
>> to write them, which also seems confusing or c) we could require them to
>> have a :, which would break compatibility.
>>
>> Personally, I don't like either of them. And perceive any readability
>> benefit to be very minor at best. I don't really see them as significantly
>> different at all.
>>
>> I also feel that we already changed from `()` to `[]` and removed the
>> `type`, to help readability. I think at some point we're just going to have
>> to accept that generic function signatures are inherently more crowded and
>> less readable and stop hoping that adding more syntax will change that.
>>
>>
>>> More importantly, while the editor highlighting will be a good thing
>>> (and could greatly benefit from the presence of the colon), it doesn't
>>> become strictly necessary.
>>>
>>
>> It already isn't strictly necessary and it won't be with type-parameters
>> either.
>>
>>
>>>
>>> Regards,
>>> Yaw
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/f67fe5d8-21a2-4b13-ab04-2935f092d727n%40googlegroups.com
>>> 
>>> .
>>>
>>
>
> --
> *Curried programmer*
> *Homepage*: http://yawboakye.com
> I'm tweeting  when I'm not coding
>  when I'm not holding my niece.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfH6BBBqZzUqzyfkMuEGoHtGq4tXdM%3DszEFUPq-QSKKXjQ%40mail.gmail.com.

Re: [go-nuts] [generics] Separating type parameters, regular parameters, and return parameters

[Yaw Boakye]

On potentially introducing backwards incompatible change, good point. I
agree that we shouldn't which means the colon would be optional.

I disagree on accepting "that generic function signatures are inherently
more crowded and less readable." I mean, inherently more crowded and less
readable looks like something that one should apologize for (1) when
teaching the language, and (2) submitting code for review. And in my
experience teaching languages, some of these non-issues (to seasoned
programmers) can be a real turn-off. If there's one reason people choose Go
over, say, Rust, it is because of Go's readability. I honestly think it can
get better, not worse. The code example I showed presents a readability
challenge, and I'm not even new to Go.

Yaw

On Fri, Nov 27, 2020 at 2:27 PM Axel Wagner 
wrote:

>
>
> On Fri, Nov 27, 2020 at 3:14 PM wher...@gmail.com 
> wrote:
>
>> I'd like to propose that we separate the type and function parameters
>> from the return parameters with a colon
>>
>
> That would mean that either a) generic and non-generic functions would
> differ by a : after the arguments, which seems confusing, or b) we could
> allow non-generic functions to also have a :, but then we'd have two ways
> to write them, which also seems confusing or c) we could require them to
> have a :, which would break compatibility.
>
> Personally, I don't like either of them. And perceive any readability
> benefit to be very minor at best. I don't really see them as significantly
> different at all.
>
> I also feel that we already changed from `()` to `[]` and removed the
> `type`, to help readability. I think at some point we're just going to have
> to accept that generic function signatures are inherently more crowded and
> less readable and stop hoping that adding more syntax will change that.
>
>
>> More importantly, while the editor highlighting will be a good thing (and
>> could greatly benefit from the presence of the colon), it doesn't become
>> strictly necessary.
>>
>
> It already isn't strictly necessary and it won't be with type-parameters
> either.
>
>
>>
>> Regards,
>> Yaw
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/f67fe5d8-21a2-4b13-ab04-2935f092d727n%40googlegroups.com
>> 
>> .
>>
>

-- 
*Curried programmer*
*Homepage*: http://yawboakye.com
I'm tweeting  when I'm not coding
 when I'm not holding my niece.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAPJoGXsnP8E7KLiM4QLPJ%3DKTY5ZkRJbU4gZ3S_Gn1MF3uQXpEw%40mail.gmail.com.

Re: [go-nuts] [generics] Separating type parameters, regular parameters, and return parameters

['Axel Wagner' via golang-nuts]

On Fri, Nov 27, 2020 at 3:14 PM wher...@gmail.com 
wrote:

> I'd like to propose that we separate the type and function parameters from
> the return parameters with a colon
>

That would mean that either a) generic and non-generic functions would
differ by a : after the arguments, which seems confusing, or b) we could
allow non-generic functions to also have a :, but then we'd have two ways
to write them, which also seems confusing or c) we could require them to
have a :, which would break compatibility.

Personally, I don't like either of them. And perceive any readability
benefit to be very minor at best. I don't really see them as significantly
different at all.

I also feel that we already changed from `()` to `[]` and removed the
`type`, to help readability. I think at some point we're just going to have
to accept that generic function signatures are inherently more crowded and
less readable and stop hoping that adding more syntax will change that.


> More importantly, while the editor highlighting will be a good thing (and
> could greatly benefit from the presence of the colon), it doesn't become
> strictly necessary.
>

It already isn't strictly necessary and it won't be with type-parameters
either.


>
> Regards,
> Yaw
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/f67fe5d8-21a2-4b13-ab04-2935f092d727n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGQWDfM%3DawMyiZpFe_8d8rHGWyo9xeY87As7dWoj1qw2g%40mail.gmail.com.

Re: [go-nuts] errors.Is and pointer arguments

[Arve Knudsen]

Thanks, Jan, but the error type in question is 3rd party so can't be
extended with Is() :)

Best,
Arve

On Fri, Nov 27, 2020 at 3:00 PM Jan Mercl <0xj...@gmail.com> wrote:

> On Fri, Nov 27, 2020 at 2:46 PM Arve Knudsen 
> wrote:
>
> > I've noticed that errors.Is returns false if you compare two error
> instances that are implemented as pointers. I.e., I'm using a struct where
> the Error method has a pointer receiver, and when passing struct instance
> pointers to errors.Is, it ends up comparing them by pointer address. Please
> see my example to see what I mean.
> >
> > Is this a bug in errors.Is or is it actually supposed to work this way?
> It really took us by surprise, and we ended up having to use errors.As
> instead since it does handle this case.
> >
> > For reference, I've already made a patch to errors.Is that changes it to
> support pointer arguments :)
>
> Alternatively https://play.golang.org/p/dUgL3IuMgY5
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEDa093fUKch%2BxoWcWYg-DNZea7w1Op-iZk407mnqAUzC8HbrQ%40mail.gmail.com.

[go-nuts] [generics] Separating type parameters, regular parameters, and return parameters

[wher...@gmail.com]

Hello,

Consider the code below (taken from the Design Draft and slightly modified):

func ConcatTo[S Stringer, P Plusser](s []S, p []P) (r []string) {
  r = make([]string, len(s))
  for i, v := range s {
r[i] = p[i].Plus(v.String())
  }
  return r
}

It becomes immediately obvious that the set of parameters become slightly 
hard to read and could require a lot of editor help (via highlight, most 
likely) to distinguish between them. I'd like to propose that we separate 
the type and function parameters from the return parameters with a colon, 
so that the above code will become:

func ConcatTo[S Stringer, P Plusser](s []S, p []P): (r []string) {
  r = make([]string, len(s))
  for i, v := range s {
r[i] = p[i].Plus(v.String())
  }
  return r
}

With the colon, the parameters are easy to scan and don't require careful 
attention in order to make out the parts. More importantly, while the 
editor highlighting will be a good thing (and could greatly benefit from 
the presence of the colon), it doesn't become strictly necessary.

Regards,
Yaw

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f67fe5d8-21a2-4b13-ab04-2935f092d727n%40googlegroups.com.

Re: [go-nuts] errors.Is and pointer arguments

[Jan Mercl]

On Fri, Nov 27, 2020 at 2:46 PM Arve Knudsen  wrote:

> I've noticed that errors.Is returns false if you compare two error instances 
> that are implemented as pointers. I.e., I'm using a struct where the Error 
> method has a pointer receiver, and when passing struct instance pointers to 
> errors.Is, it ends up comparing them by pointer address. Please see my 
> example to see what I mean.
>
> Is this a bug in errors.Is or is it actually supposed to work this way? It 
> really took us by surprise, and we ended up having to use errors.As instead 
> since it does handle this case.
>
> For reference, I've already made a patch to errors.Is that changes it to 
> support pointer arguments :)

Alternatively https://play.golang.org/p/dUgL3IuMgY5

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-XgHLA%2BC%2BQ2gqY4GwnG0XLeMMkhp15SUZfkq5jHsA7O3A%40mail.gmail.com.

[go-nuts] Re: errors.Is and pointer arguments

[Arve Knudsen]

Actually, never mind about this. I realized in the meantime that I 
shouldn't be using `errors.Is` in this case, where I basically want to see 
if the error is of a certain type. `errors.As` makes more sense for this 
use case.

On Friday, November 27, 2020 at 2:46:36 PM UTC+1 Arve Knudsen wrote:

> Hello!
>
> I've noticed that errors.Is returns false if you compare two error 
> instances that are implemented as pointers. I.e., I'm using a struct where 
> the Error method has a pointer receiver, and when passing struct instance 
> pointers to errors.Is, it ends up comparing them by pointer address. Please 
> see my example  to see what I mean.
>
> Is this a bug in errors.Is or is it actually supposed to work this way? It 
> really took us by surprise, and we ended up having to use errors.As instead 
> since it does handle this case.
>
> For reference, I've already made a patch to errors.Is that changes it to 
> support pointer arguments :)
>
> Best,
> Arve
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c2ac60e5-d8a5-4e27-a307-97ade8f169fbn%40googlegroups.com.

[go-nuts] errors.Is and pointer arguments

[Arve Knudsen]

Hello!

I've noticed that errors.Is returns false if you compare two error 
instances that are implemented as pointers. I.e., I'm using a struct where 
the Error method has a pointer receiver, and when passing struct instance 
pointers to errors.Is, it ends up comparing them by pointer address. Please 
see my example  to see what I mean.

Is this a bug in errors.Is or is it actually supposed to work this way? It 
really took us by surprise, and we ended up having to use errors.As instead 
since it does handle this case.

For reference, I've already made a patch to errors.Is that changes it to 
support pointer arguments :)

Best,
Arve

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/83c4aa33-fd73-498d-ac03-d5b1585204d1n%40googlegroups.com.

Re: [go-nuts] How to detect HTTP client stop polling at the server side

[b.ca...@pobox.com]

I should add: using channels often means the mutex is not required.

Imagine, for example, that you want a concurrency-safe counter (that 
multiple goroutines can read, increment and decrement).  You can put the 
counter value into a buffered channel:

counter := make(chan int, 1)
counter <- 0

Then you pull the value out of channel while you're working on it, and put 
it back when you're finished.

// Read counter
cv := <- counter
fmt.Println("Counter is %d", cv)
counter <- cv

// Increment counter
counter <- (<-counter + 1)

This is all safe because only one goroutine has possession of the counter 
value at any time.  Just make sure you always put it back (it can be 
helpful to write functions to do the accessing, and use 'defer' to put the 
value back)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c6de9b79-857c-41fd-bcb2-f62f1ddd7e71n%40googlegroups.com.

Re: [go-nuts] concurrency safety

[b.ca...@pobox.com]

On Friday, 27 November 2020 at 10:32:11 UTC oyvin...@teigfam.net wrote:

> Thread safety, concurrency safety, goroutines safety. The same stuff to 
> me.  
>
> It's important that concurrent goroutines don't interfere with each other 
> in such a way that internal state is compromised by other goroutines. 
> Typically through access to internal data, through pointers.
>

Not just that, but also:

-  any global variables.  Even reading an 'int' while some other goroutine 
is updating it is unsafe; it may give undefined behavior.

- concurrent read and write accesses to the same map or slice can cause the 
program to panic.  Note that map and slice values contain hidden pointers 
inside them.  So if two goroutines have the same map or slice value, they 
are aliasing to the same underlying data.

These can trip up people used to (say) Python, where such accesses are 
atomic - primarily because of Python's Global Interpreter Lock.

(There is sync.Map  which is 
concurrency-safe, but if you need this, there's probably a better solution 
in your architecture)
 

> If only go channels are used to communicate between goroutines, than that 
> case is closed. That's one of the reasons they exist - also in other 
> similar languages, with that aspect often based on CSP.
>

Here's a video explaining how channels can replace various concurrency 
primitives: it's worth getting your head around.
https://www.youtube.com/watch?v=5zXAHh5tJqQ

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/57144fb7-712b-4bde-9ed4-f98c06c27241n%40googlegroups.com.

Re: [go-nuts] Re: mount remote storage without FUSE

['Axel Wagner' via golang-nuts]

Yeah, NFS would work as well (similar tradeoffs as 9P, though the linux
kernel driver might perform better because it's more widely used).

nbd is not suitable for the use case, I think :) I'd also recommend against
using my nbd package if performance is the goal - it is not at all
optimized, I wrote it mostly as a tool to test filesystem implementations
and things that depend on certain filesystem semantics.

On Fri, Nov 27, 2020 at 11:26 AM Didier Spezia  wrote:

> One possibility is to use the 9P client of the kernel and implements a 9P
> server in Go - there are a few 9P libraries for Go around.
> I doubt it will be more efficient than FUSE though, and btw FUSE is
> largely based on the ideas promoted by 9P.
>
> Another possibility is to use the ndb client of the kernel and implements
> a ndb server in Go. See Axel's ndb package at
> https://github.com/Merovius/nbd
> Now ndb exposes a block device, not a filesystem. I think I would be quite
> difficult to emulate the format of one the filesystems supported by the
> kernel and implements it in this Go ndb server.
>
> Regards,
> Didier.
>
>
>
>
> Le mercredi 25 novembre 2020 à 09:38:02 UTC+1, ChrisLu a écrit :
>
>> Hi, Gophers (who are also good in C),
>>
>> Currently I am using FUSE to mount and write to remote storage.
>> The library I am using is Basil Fuse. The performance is good as far as
>> FUSE can go.
>>
>> User -> file.write() -> Linux Kernel -> Virtual File System -> libfuse ->
>> FUSE -> DFS Client(in Go) -> Remote Storage
>>
>> However, I am researching how to write directly through linux virtual
>> file system, skipping FUSE layer. Seems all similar libraries are in C. Is
>> this even possible in Go?
>>
>> User -> file.write() -> Linux Kernel -> Virtual File System -> DFS
>> Client(in Go) -> Remote Storage
>>
>> Thanks!
>>
>> Chris
>> https://github.com/chrislusf/seaweedfs
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/835bbe35-6845-4d44-98b9-83a07c86b79bn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGUvxmx5%2BhB4uuu6y6qMc6NihhSHmStFs4trYygoZh2QA%40mail.gmail.com.

Re: [go-nuts] concurrency safety

[Øyvind Teig]

Thread safety, concurrency safety, goroutines safety. The same stuff to me. 
 

It's important that concurrent goroutines don't interfere with each other 
in such a way that internal state is compromised by other goroutines. 
Typically through access to internal data, through pointers. If only go 
channels are used to communicate between goroutines, than that case is 
closed. That's one of the reasons they exist - also in other similar 
languages, with that aspect often based on CSP.

But then, goroutines may communicate in a circle, the smallest would be two 
sending to each other and awaiting answer from each other at the "same" 
time. A system would easily freeze from this point and out. This would 
cause deadlock, which is pathological. Using deadlock free patterns may 
solve that problem from the beginning, provided such a pattern is used 
correctly. 

Finally(?), one goroutine could be busy by itself, or by communicating with 
others, so that it is not able to read vital messages from other 
goroutines, ever. This would be a livelock. 

I think go comes with a tool [1] that would help for some of these types of 
problems. I have not tested it myself, since I use another, embedded 
concurrent language. But I do read these mail lists every time they come, 
so I try to learn what this community is up to.

There would be ways whereby one could model concurrent programs as well. 
Lots of modelling languages exist. Myself I have to some extent used CSPm 
(with the FDR tool), FSP (with the LTSA tool) and Promela (with the Spin 
tool).

[1] https://golang.org/doc/articles/race_detector.html

torsdag 26. november 2020 kl. 03:55:06 UTC+1 skrev Ian Lance Taylor:

> On Wed, Nov 25, 2020 at 6:13 PM Alexey Dvoretskiy
>  wrote:
> >
> > How would you cal "thread-safety" in Go? Go doesn't have threads so the 
> term "thread-safety" sounds bit off.
>
> The standard library says things like "Multiple goroutines may invoke
> methods on a Conn simultaneously" (from
> https://golang.org/pkg/net/#Conn).
>
> Terms like "thread safety" can come with various caveats and
> restrictions, so it's usually best to avoid just saying "thread safe"
> in general purpose documentations. Better to try to say more
> precisely what is and what is not supported.
>
> Ian
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/97d39db9-fd05-4f57-a3a5-50ff2eb8f298n%40googlegroups.com.

[go-nuts] Re: mount remote storage without FUSE

[Didier Spezia]

One possibility is to use the 9P client of the kernel and implements a 9P 
server in Go - there are a few 9P libraries for Go around.
I doubt it will be more efficient than FUSE though, and btw FUSE is largely 
based on the ideas promoted by 9P.

Another possibility is to use the ndb client of the kernel and implements a 
ndb server in Go. See Axel's ndb package at https://github.com/Merovius/nbd
Now ndb exposes a block device, not a filesystem. I think I would be quite 
difficult to emulate the format of one the filesystems supported by the 
kernel and implements it in this Go ndb server.

Regards,
Didier.




Le mercredi 25 novembre 2020 à 09:38:02 UTC+1, ChrisLu a écrit :

> Hi, Gophers (who are also good in C),
>
> Currently I am using FUSE to mount and write to remote storage. 
> The library I am using is Basil Fuse. The performance is good as far as 
> FUSE can go.
>
> User -> file.write() -> Linux Kernel -> Virtual File System -> libfuse -> 
> FUSE -> DFS Client(in Go) -> Remote Storage
>
> However, I am researching how to write directly through linux virtual file 
> system, skipping FUSE layer. Seems all similar libraries are in C. Is this 
> even possible in Go?
>
> User -> file.write() -> Linux Kernel -> Virtual File System -> DFS 
> Client(in Go) -> Remote Storage
>
> Thanks! 
>
> Chris
> https://github.com/chrislusf/seaweedfs
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/835bbe35-6845-4d44-98b9-83a07c86b79bn%40googlegroups.com.

Re: [go-nuts] How to detect HTTP client stop polling at the server side

[Afriyie Abraham Kwabena]

Hi,

THanks!!

BR
Abraham

On Friday, November 27, 2020 at 11:12:53 AM UTC+2 b.ca...@pobox.com wrote:

> On Friday, 27 November 2020 at 06:14:48 UTC Afriyie Abraham Kwabena wrote:
>
>> What I would like to ask is, using mutex OK and if not the best way of 
>> solving it, how can i use
>> channels in this case.
>>
>
> There's nothing wrong with mutex, but you can use channels for a more 
> native-Go experience.
> This video is well worth watching: 
> https://www.youtube.com/watch?v=5zXAHh5tJqQ
>
> In short, you can get mutex or semaphore-like behaviour by having a 
> channel with fixed depth, and putting/pulling values from it.
> Playground 
>
> mutex := make(chan struct{}, 1)
> ...
>
> mutex <- struct{}{}
> ... do stuff
> <-mutex
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e59c6a22-030c-479a-ba8a-b61948307b62n%40googlegroups.com.

Re: [go-nuts] How to detect HTTP client stop polling at the server side

[b.ca...@pobox.com]

On Friday, 27 November 2020 at 06:14:48 UTC Afriyie Abraham Kwabena wrote:

> What I would like to ask is, using mutex OK and if not the best way of 
> solving it, how can i use
> channels in this case.
>

There's nothing wrong with mutex, but you can use channels for a more 
native-Go experience.
This video is well worth 
watching: https://www.youtube.com/watch?v=5zXAHh5tJqQ

In short, you can get mutex or semaphore-like behaviour by having a channel 
with fixed depth, and putting/pulling values from it.
Playground 

mutex := make(chan struct{}, 1)
...

mutex <- struct{}{}
... do stuff
<-mutex

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a3c1e84d-5d68-4862-a94a-9180ae943485n%40googlegroups.com.