[go-nuts] Re: Which websockets implementation

[Jason E. Aten]

gorrila/websocket is a very mature library. The current maintainer stepping 
down doesn't change that. 
I wouldn't avoid it. The very fact that its been so stable and successful 
for so long that there's
nothing left to do on it is actually a recommendation.

Nice tutorial:

https://blog.markvincze.com/programmatically-refreshing-a-browser-tab-from-a-golang-application/



On Monday, December 12, 2022 at 12:57:19 PM UTC-6 Amnon wrote:

> Which websocket implementation would people recommend for a new project,
> now that gorilla/websocket has been archived?

-- 
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/cdb789e5-0651-48a6-bf8c-d3d9f085fef0n%40googlegroups.com.

Re: [go-nuts] Re: App Engine hasn't upgraded beyond Go 1.16, which is now out of security window

[Sean Abraham]

Thanks, folks! I just upgraded my app to the 119 runtime too, and it went
very smoothly!

On Mon, Dec 19, 2022 at 11:40 AM 'drc...@google.com' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> I just checked with my personal app engine project ("gcloud app deploy",
> that's app engine, I think), and with 1.19 specified in go.mod and
> "runtime: 119" in app.yaml, the app reported runtime.Version() of 1.19.3.
> My understanding is this is a recent change.
>
> On Thursday, December 15, 2022 at 11:33:41 AM UTC-5 Olivier Favre wrote:
>
>> Hi,
>>
>> I think App Engine is not getting as much development efforts as Cloud
>> Run does.
>> I foresee it the same fate as Legacy Networks versus VPC.
>>
>> That said, it looks like they were unconfortable with this situation as
>> they released Go 1.18 and 1.19 (NB: not 1.17) a few days ago:
>>
>> https://cloud.google.com/appengine/docs/standard/go/release-notes#December_07_2022
>>
>> Cheers,
>> --
>> Olivier Favre
>>
>> On Monday, September 12, 2022 at 11:33:09 AM UTC+2 Rusco wrote:
>>
>>> Googles own language on Googles own cloud lags behind several version,
>>> I don't understand this :-(
>>>
>>> Microsoft seems to be more eager to keep things up to date:
>>> .NET 7 comes to Azure Functions & Visual Studio 2022 - .NET Blog
>>> (microsoft.com)
>>> 
>>>
>>> On Monday, 12 September 2022 at 02:33:18 UTC+1 seana...@gmail.com wrote:
>>>
 I'm hoping a member of the Go team will take pity on me and prod the
 App Engine Go team about this. The most recent upgrade to AE's Go
 environment was in Nov 2021, when they started supporting Go 1.16 (see
 release notes below). Now that Go 1.19 is out, Go 1.16 won't be getting
 security fixes anymore, and App Engine Go users are in a frustrating place.

 If this is App Engine's way of telling me to move to Cloud Run
 (-->Dockerizing), it'd be nice if they'd just tell us that :). Otherwise,
 could a Googler please help us AE users out and poke AE into getting up to
 1.17, 1.18, or 1.19? I don't know where to file a bug straight against AE,
 and I figure the Go team should be very interested in this, due to
 aforementioned security implications.

 https://cloud.google.com/appengine/docs/standard/go/release-notes

 Thanks,
 Sean

>>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/OspOyUz7CBQ/unsubscribe.
> To unsubscribe from this group and all its topics, 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/5844eecc-9315-41a7-957e-39c6bd46a0bcn%40googlegroups.com
> 
> .
>


-- 
Sean Abraham
seanabra...@gmail.com
Cell: 720-278-8211

-- 
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/CA%2BfUVwNfHXnZkb3XkduD-hCSzBT6P8hxPfR-50OnBoGBauMWEQ%40mail.gmail.com.

[go-nuts] Re: Which websockets implementation

[Juliusz Chroboczek]

> By stdlib, you presumably mean the x/net/websocket package,

Careful with this library, it's not quite correct.  Websocket is
a frame-oriented protocol, while x/net/websocket implements a simplistic
API that does not always preserve frame boundaries.

Correct implementations include:

  https://github.com/gorilla/websocket
  https://github.com/nhooyr/websocket

-- Juliusz

-- 
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/87sfhaajyb.fsf%40pirx.irif.fr.

[go-nuts] Re: Why there are eight bytes pad in the stack frame of main function?

['Keith Randall' via golang-nuts]

Q1: stack frames are rounded to a multiple of 8 bytes, to keep the stack 
pointer 8-byte aligned. Part of that is rounding argsize to 8 bytes. (It's 
not strictly necessary, and we could report 4, I think, if there are no 
return values.)
Q2: I think 4 are from rounding argsize up to 8 bytes, and 4 are padding to 
keep the total frame a multiple of 8 bytes.
Q3: offsets are from the updated stack pointer (the one generated by the 
SUBQ $24, SP instruction). So they will be positive.

On Monday, December 19, 2022 at 11:31:47 AM UTC-8 tarorual wrote:

> package main
>
> func main() {
>   var x int32 = 1
>   nop(x)
> }
>
> //go:noinline
> func nop(x int32) {}
>
> *Go version: go1.16.15 windows/amd64*
>
> I wrote above code and compiled it into assembly with `go1.16.15 tool 
> compile -S -N -l main.go` for truly understanding Go functions call.
>
> The following is the assembly code of nop function:
>
> "".nop STEXT nosplit size=1 args=0x8 locals=0x0 funcid=0x0
> 0x 0 (main.go:9)TEXT"".nop(SB), 
> NOSPLIT|ABIInternal, $0-8
> 0x 0 (main.go:9)FUNCDATA$0, 
> gclocals·33cdeebe80329f1fdbee7f5874cb(SB)
> 0x 0 (main.go:9)FUNCDATA$1, 
> gclocals·33cdeebe80329f1fdbee7f5874cb(SB)
> 0x 0 (main.go:9)RET
>
> Obviously, the nop function returns directly without doing anything. It 
> only has a `int32` type parameter, but we can see the `argsize` is 8 bytes 
> in the assembly:
>
> TEXT"".nop(SB), NOSPLIT|ABIInternal, $0-*8*
>
> *Question1: Why the `argsize` is 8 bytes not 4 bytes?*
>
> The following is the assembly code of main function:
>
> "".main STEXT size=73 args=0x0 locals=0x18 funcid=0x0
> 0x 0 (main.go:3)TEXT"".main(SB), ABIInternal, 
> $24-0
> 0x 0 (main.go:3)MOVQTLS, CX
> 0x0009 9 (main.go:3)PCDATA  $0, $-2
> 0x0009 9 (main.go:3)MOVQ(CX)(TLS*2), CX
> 0x0010 00016 (main.go:3)PCDATA  $0, $-1
> 0x0010 00016 (main.go:3)CMPQSP, 16(CX)
> 0x0014 00020 (main.go:3)PCDATA  $0, $-2
> 0x0014 00020 (main.go:3)JLS 66
> 0x0016 00022 (main.go:3)PCDATA  $0, $-1
> 0x0016 00022 (main.go:3)SUBQ$24, SP
> 0x001a 00026 (main.go:3)MOVQBP, 16(SP)
> 0x001f 00031 (main.go:3)LEAQ16(SP), BP
> 0x0024 00036 (main.go:3)FUNCDATA$0, 
> gclocals·33cdeebe80329f1fdbee7f5874cb(SB)
> 0x0024 00036 (main.go:3)FUNCDATA$1, 
> gclocals·33cdeebe80329f1fdbee7f5874cb(SB)
> 0x0024 00036 (main.go:4)MOVL$1, "".x+12(SP)
> 0x002c 00044 (main.go:5)MOVL$1, (SP)
> 0x0033 00051 (main.go:5)PCDATA  $1, $0
> 0x0033 00051 (main.go:5)CALL"".nop(SB)
> 0x0038 00056 (main.go:6)MOVQ16(SP), BP
> 0x003d 00061 (main.go:6)ADDQ$24, SP
> 0x0041 00065 (main.go:6)RET
>
> I drawn a picture of stack according to the assembly code:
> https://i.stack.imgur.com/AHN1b.png
>
> *Question2: I find there are confusing 8 bytes in the stack, why do these 
> 8 bytes exist?*
>
> * Question3:  Why *MOVL$1, "".x*+*12(SP)*but not  *MOVL$1, "".x*-*
> 12(SP)? 
>
> I think memory alignment causes the above phenomenon, but I'm not sure.

-- 
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/1f039f1b-c5b9-49b1-a908-428b0651b712n%40googlegroups.com.

Re: [go-nuts] Language idea: Improved support for method-like functions

['Axel Wagner' via golang-nuts]

On Mon, Dec 19, 2022 at 8:31 PM Red Daly  wrote:

> Methods cannot take type arguments, so I find myself writing `func Foo(o
> Object) {...}` instead of `func (o Object) Foo()` in cases where Foo needs
> a type parameter.
>
> I would like some type of pseudo-method in Go similar to Kotlin's
> extension methods. Made up syntax:
>
> ```go
> package foo
>
> func (o Object) #Foo[T any]() { /* ... */ } // Foo is a pseudo method of
> Object
>
> func main() {
>   obj := Object{}
>   obj#Foo() // use # to differentiate from regular methods, or use .
> }
> ```
> or something more clever.
>
> I expect a lot of the time people use methods for syntactic reasons, not
> so those methods can be used to implement an interface. Methods appear in
> godoc along with the type, get better tab completion than functions, etc.
> I'm not proposing these pseudo-methods be used in any way to implement
> interfaces.
>
> This may have already been discussed. There have been rejected proposals
> for adding methods to types defined elsewhere (
> https://github.com/golang/go/issues/37742 and
> https://github.com/golang/go/issues/21401). However, I can't find a
> proposal that proposes the Kotlin approach to "extension methods," which is
> largely syntax sugar that allows `fun koo(k Kobject): void` to be called
> like `k.koo()` by the programmer (rather than `koo(k)`) so long as `koo` is
> statically resolved where such `k.koo` calls appear. Is there such a
> proposal?
>

There are (at least) two:
https://github.com/golang/go/issues/56283
https://github.com/golang/go/issues/56242
It's not *exactly* what you describe, but I believe it's close enough.


>
> This feature would be useful for defining these pseudo-methods on types
> within a package or on types from other packages. Using a pseudo-receiver
> type that's defined in another package raises some questions about how to
> use the pseudo-method without surprising/confusing readers. Most
> prominently for writing method-like generic functions.
>
> --
> 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/e8685cd7-4691-4b74-8c9a-b4a8992dbd20n%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/CAEkBMfHnj_xWRw_qsii3V0Sdqq3_%3DoZxzXxxkH5BzZKwjXMPDw%40mail.gmail.com.

Re: [go-nuts] Is OCSP Stapling supported in Go? If so, how?

['Sean Liao' via golang-nuts]

The standard library itself doesn't do it, but it does provide you with
hooks to do so.
Set crypto/tls.Config.GetCertificate to an appropriate implementation of
OCSP stapling.
Examples of ocsp stapling can be found via the package discovery site:
https://pkg.go.dev/search?q=ocsp+staple

- sean


On Mon, Dec 19, 2022 at 7:31 PM John Wayne  wrote:

> I tried to google this for a while now, and all I find regarding this
> topic is: https://groups.google.com/g/golang-nuts/c/QC5FOysyVxg
>
> This is already many years old, and to me it seems like there is code
> inside Go which allows to perform server side OCSP stapling. However, I am
> unable to find out *how* one would use this. Does this just work
> transparently in the background, all done by the Go library itself, or does
> the developer need to take measures when implementing an HTTP server using
> Go?
>
> I would test this out myself, but testing whether or not a given server
> provides the OCSP response in the handshake is not exactly trivial, since
> you would need to have a proper certificate with a working OCSP responder
> set up, which I don't.
>
> So I would really appreciate if someonce could shed a bit of light on this
> topic for me.
>
> Thanks!
>
> --
> 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/99634c56-6357-48b8-887f-9d27067182fan%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/CAGabyPou1ocoiKxAK0CPVDZ1C9UJnftqEhLnq61W_16gkm%2BbQg%40mail.gmail.com.

Re: [go-nuts] the example always fails if the string contains a trailing space before a newline

['Sean Liao' via golang-nuts]

https://go.dev/issue/26460

- sean


On Mon, Dec 19, 2022 at 7:31 PM David M  wrote:

> Not quite sure if this is a bug but it's annoying:
>
> If the example tested string contains a trailing space before a newline,
> the test always fails no matter how.
> // this test passes
> func ExampleFormat() {
> fmt.Println("a\nb")
> // Output:
> // a
> // b
> }
> // this test fails no matter we put "a" or "a " in the first output line.
> func ExampleFormat() {
> fmt.Println("a \nb")
> // Output:
> // a
> // b
>  }
>
> The doc  says "The comparison
> ignores leading and trailing space." I guess what's going on here is that
> it cut the trailing space in the desired output, but doesn't handle the
> space in the practical output if it's before a newline. Because the
> practical output may come from a 3rd party library, we have to respect how
> they print things.
>
> --
> 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/c24ffdb6-bde2-43be-b2ed-9735752bfb95n%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/CAGabyPobV%3DZZt2jV5yAjEkDffssnCZskrAFc1WG3%2BwvLV45tpw%40mail.gmail.com.

[go-nuts] Is OCSP Stapling supported in Go? If so, how?

[John Wayne]

I tried to google this for a while now, and all I find regarding this topic 
is: https://groups.google.com/g/golang-nuts/c/QC5FOysyVxg

This is already many years old, and to me it seems like there is code 
inside Go which allows to perform server side OCSP stapling. However, I am 
unable to find out *how* one would use this. Does this just work 
transparently in the background, all done by the Go library itself, or does 
the developer need to take measures when implementing an HTTP server using 
Go?

I would test this out myself, but testing whether or not a given server 
provides the OCSP response in the handshake is not exactly trivial, since 
you would need to have a proper certificate with a working OCSP responder 
set up, which I don't.

So I would really appreciate if someonce could shed a bit of light on this 
topic for me.

Thanks!

-- 
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/99634c56-6357-48b8-887f-9d27067182fan%40googlegroups.com.

[go-nuts] the example always fails if the string contains a trailing space before a newline

[David M]

Not quite sure if this is a bug but it's annoying:

If the example tested string contains a trailing space before a newline, 
the test always fails no matter how.
// this test passes 
func ExampleFormat() {
fmt.Println("a\nb")
// Output:
// a 
// b 
}
// this test fails no matter we put "a" or "a " in the first output line. 
func ExampleFormat() { 
fmt.Println("a \nb") 
// Output:
// a
// b
 }

The doc  says "The comparison 
ignores leading and trailing space." I guess what's going on here is that 
it cut the trailing space in the desired output, but doesn't handle the 
space in the practical output if it's before a newline. Because the 
practical output may come from a 3rd party library, we have to respect how 
they print things.

-- 
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/c24ffdb6-bde2-43be-b2ed-9735752bfb95n%40googlegroups.com.

[go-nuts] Why there are eight bytes pad in the stack frame of main function?

[tarorual]

package main

func main() {
  var x int32 = 1
  nop(x)
}

//go:noinline
func nop(x int32) {}

*Go version: go1.16.15 windows/amd64*

I wrote above code and compiled it into assembly with `go1.16.15 tool 
compile -S -N -l main.go` for truly understanding Go functions call.

The following is the assembly code of nop function:

"".nop STEXT nosplit size=1 args=0x8 locals=0x0 funcid=0x0
0x 0 (main.go:9)TEXT"".nop(SB), 
NOSPLIT|ABIInternal, $0-8
0x 0 (main.go:9)FUNCDATA$0, 
gclocals·33cdeebe80329f1fdbee7f5874cb(SB)
0x 0 (main.go:9)FUNCDATA$1, 
gclocals·33cdeebe80329f1fdbee7f5874cb(SB)
0x 0 (main.go:9)RET

Obviously, the nop function returns directly without doing anything. It 
only has a `int32` type parameter, but we can see the `argsize` is 8 bytes 
in the assembly:

TEXT"".nop(SB), NOSPLIT|ABIInternal, $0-*8*

*Question1: Why the `argsize` is 8 bytes not 4 bytes?*

The following is the assembly code of main function:

"".main STEXT size=73 args=0x0 locals=0x18 funcid=0x0
0x 0 (main.go:3)TEXT"".main(SB), ABIInternal, 
$24-0
0x 0 (main.go:3)MOVQTLS, CX
0x0009 9 (main.go:3)PCDATA  $0, $-2
0x0009 9 (main.go:3)MOVQ(CX)(TLS*2), CX
0x0010 00016 (main.go:3)PCDATA  $0, $-1
0x0010 00016 (main.go:3)CMPQSP, 16(CX)
0x0014 00020 (main.go:3)PCDATA  $0, $-2
0x0014 00020 (main.go:3)JLS 66
0x0016 00022 (main.go:3)PCDATA  $0, $-1
0x0016 00022 (main.go:3)SUBQ$24, SP
0x001a 00026 (main.go:3)MOVQBP, 16(SP)
0x001f 00031 (main.go:3)LEAQ16(SP), BP
0x0024 00036 (main.go:3)FUNCDATA$0, 
gclocals·33cdeebe80329f1fdbee7f5874cb(SB)
0x0024 00036 (main.go:3)FUNCDATA$1, 
gclocals·33cdeebe80329f1fdbee7f5874cb(SB)
0x0024 00036 (main.go:4)MOVL$1, "".x+12(SP)
0x002c 00044 (main.go:5)MOVL$1, (SP)
0x0033 00051 (main.go:5)PCDATA  $1, $0
0x0033 00051 (main.go:5)CALL"".nop(SB)
0x0038 00056 (main.go:6)MOVQ16(SP), BP
0x003d 00061 (main.go:6)ADDQ$24, SP
0x0041 00065 (main.go:6)RET

I drawn a picture of stack according to the assembly code:
https://i.stack.imgur.com/AHN1b.png

*Question2: I find there are confusing 8 bytes in the stack, why do these 8 
bytes exist?*

* Question3:  Why *MOVL$1, "".x*+*12(SP)*but not  *MOVL$1, "".x*-*
12(SP)? 

I think memory alignment causes the above phenomenon, but I'm not sure.

-- 
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/4f87acc6-def5-414b-b835-7f1e6ee192ddn%40googlegroups.com.

[go-nuts] Language idea: Improved support for method-like functions

[Red Daly]

Methods cannot take type arguments, so I find myself writing `func Foo(o 
Object) {...}` instead of `func (o Object) Foo()` in cases where Foo needs 
a type parameter.

I would like some type of pseudo-method in Go similar to Kotlin's extension 
methods. Made up syntax:

```go
package foo

func (o Object) #Foo[T any]() { /* ... */ } // Foo is a pseudo method of 
Object

func main() {
  obj := Object{}
  obj#Foo() // use # to differentiate from regular methods, or use .
}
```
or something more clever.

I expect a lot of the time people use methods for syntactic reasons, not so 
those methods can be used to implement an interface. Methods appear in 
godoc along with the type, get better tab completion than functions, etc. 
I'm not proposing these pseudo-methods be used in any way to implement 
interfaces.

This may have already been discussed. There have been rejected proposals 
for adding methods to types defined elsewhere 
(https://github.com/golang/go/issues/37742 
and https://github.com/golang/go/issues/21401). However, I can't find a 
proposal that proposes the Kotlin approach to "extension methods," which is 
largely syntax sugar that allows `fun koo(k Kobject): void` to be called 
like `k.koo()` by the programmer (rather than `koo(k)`) so long as `koo` is 
statically resolved where such `k.koo` calls appear. Is there such a 
proposal?

This feature would be useful for defining these pseudo-methods on types 
within a package or on types from other packages. Using a pseudo-receiver 
type that's defined in another package raises some questions about how to 
use the pseudo-method without surprising/confusing readers. Most 
prominently for writing method-like generic functions.

-- 
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/e8685cd7-4691-4b74-8c9a-b4a8992dbd20n%40googlegroups.com.

[go-nuts] Re: App Engine hasn't upgraded beyond Go 1.16, which is now out of security window

['drc...@google.com' via golang-nuts]

I just checked with my personal app engine project ("gcloud app deploy", 
that's app engine, I think), and with 1.19 specified in go.mod and 
"runtime: 119" in app.yaml, the app reported runtime.Version() of 1.19.3.  
My understanding is this is a recent change.

On Thursday, December 15, 2022 at 11:33:41 AM UTC-5 Olivier Favre wrote:

> Hi,
>
> I think App Engine is not getting as much development efforts as Cloud Run 
> does.
> I foresee it the same fate as Legacy Networks versus VPC.
>
> That said, it looks like they were unconfortable with this situation as 
> they released Go 1.18 and 1.19 (NB: not 1.17) a few days ago:
>
> https://cloud.google.com/appengine/docs/standard/go/release-notes#December_07_2022
>
> Cheers,
> --
> Olivier Favre
>
> On Monday, September 12, 2022 at 11:33:09 AM UTC+2 Rusco wrote:
>
>> Googles own language on Googles own cloud lags behind several version,  I 
>> don't understand this :-( 
>>
>> Microsoft seems to be more eager to keep things up to date: 
>> .NET 7 comes to Azure Functions & Visual Studio 2022 - .NET Blog 
>> (microsoft.com) 
>> 
>>
>> On Monday, 12 September 2022 at 02:33:18 UTC+1 seana...@gmail.com wrote:
>>
>>> I'm hoping a member of the Go team will take pity on me and prod the App 
>>> Engine Go team about this. The most recent upgrade to AE's Go environment 
>>> was in Nov 2021, when they started supporting Go 1.16 (see release notes 
>>> below). Now that Go 1.19 is out, Go 1.16 won't be getting security fixes 
>>> anymore, and App Engine Go users are in a frustrating place.
>>>
>>> If this is App Engine's way of telling me to move to Cloud Run 
>>> (-->Dockerizing), it'd be nice if they'd just tell us that :). Otherwise, 
>>> could a Googler please help us AE users out and poke AE into getting up to 
>>> 1.17, 1.18, or 1.19? I don't know where to file a bug straight against AE, 
>>> and I figure the Go team should be very interested in this, due to 
>>> aforementioned security implications.
>>>
>>> https://cloud.google.com/appengine/docs/standard/go/release-notes
>>>
>>> Thanks,
>>> Sean
>>>
>>

-- 
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/5844eecc-9315-41a7-957e-39c6bd46a0bcn%40googlegroups.com.

[go-nuts] Re: Context cancellation: Is it sufficient to make long-running things interruptible?

[Brian Candler]

It depends entirely on your application, and how the various goroutines are 
wired together with channels.

But as a guiding principle: I'd say that anything which *sends* on a 
channel should close it when it's finished - whether that be due to context 
cancellation, or some other reason. Anything that *consumes* from a channel 
should keep consuming until it's closed. The consumer doesn't need to check 
for context cancellation, because it will stop when the channel is closed 
anyway.

If you wrote it so that the consumer independently notices the cancellation 
signal and stops consuming, then you risk the sending goroutine blocking 
forever.

-- 
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/1d457c64-74f7-4523-8274-f3e587d960abn%40googlegroups.com.

[go-nuts] Re: Context cancellation: Is it sufficient to make long-running things interruptible?

[Torsten Bronger]

Hallöchen!

Brian Candler writes:

> On Monday, 19 December 2022 at 12:01:39 UTC Torsten Bronger wrote:
>
>> But would you agree that additional checking is necessary if
>> DoSomething does not have a ctx argument?
>
> Given that you're running DoSomething synchronously, it will always
> run to completion.  So you'll always have a valid data value to send.
>
> Do you want to throw this value away if the context was cancelled in
> the mean time?  You can do this:
>
> select {
> case <-ctx.Done():
> return ctx.Err()
> default:
> select {
> case <-ctx.Done():
> return ctx.Err()
> case out <- v:
> }
> }

Yes, this is what I had in mind.  (Or something very similar;
instead of the first “case”, an extra check of ctx.Err() at top
level.)

> [...]
>
> TBH, I don't like the idea of a function sending or not sending a
> message on a channel randomly (depending on whether the context
> was cancelled); it's a recipe for deadlocks IMO.  You should
> consider either closing the 'out' channel, or sending a
> termination message down it, to signal that there's no more data.
> I would use *that* as the trigger to terminate the receiver,
> rather than the context cancellation.

I have an error channel that unblocks the receiver (and stops it
from expecting more data).

But here I am worried about terminating the *sender* timely.  Does
cancellation mean that I should end the current loop whatever it
takes or that I should end ASAP?

Regards,
Torsten.

-- 
Torsten Bronger

-- 
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/87ili79z88.fsf%40physik.rwth-aachen.de.

[go-nuts] Re: Context cancellation: Is it sufficient to make long-running things interruptible?

[Brian Candler]

On Monday, 19 December 2022 at 12:01:39 UTC Torsten Bronger wrote:

> But would you agree that additional checking is necessary if 
> DoSomething does not have a ctx argument?
>

Given that you're running DoSomething synchronously, it will always run to 
completion.  So you'll always have a valid data value to send.

Do you want to throw this value away if the context was cancelled in the 
mean time?  You can do this:

select {
case <-ctx.Done():
return ctx.Err()
default:
select {
case <-ctx.Done():
return ctx.Err()
case out <- v:
}
}

I included the second <-ctx.Done() because if out<-v is blocking for a long 
time, you still might want to be able to cancel

Note that there is a race condition in this code: the context could be 
cancelled at any time even after DoSomething has completed.  You have to 
allow that the value v *may or may not* be sent, depending on exactly when 
the cancellation signal arrived.

Given that you already have a valid value from DoSomething you could decide 
to send it regardless, and then test for cancellation.  But that depends on 
the receiver remaining ready to receive this value.

for {
  v, err := DoSomething()
  if err != nil {
return err
  }
  out <- v
  select {
  case <-ctx.Done():
return ctx.Err()
  }
}

TBH, I don't like the idea of a function sending or not sending a message 
on a channel randomly (depending on whether the context was cancelled); 
it's a recipe for deadlocks IMO.  You should consider either closing the 
'out' channel, or sending a termination message down it, to signal that 
there's no more data.  I would use *that* as the trigger to terminate the 
receiver, rather than the context cancellation.

-- 
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/24f681e9-a1b8-4061-8fb0-3cfb54847e07n%40googlegroups.com.

[go-nuts] Re: Context cancellation: Is it sufficient to make long-running things interruptible?

[Torsten Bronger]

Hallöchen!

Jan Mercl writes:

> [...]
>
> From https://go.dev/ref/spec#Select_statements
>
> 
> 2. If one or more of the communications can proceed, a single one that
> can proceed is chosen via a uniform pseudo-random selection.
> 
>
> Selecting the send case in the above code, when both cases can
> proceed, for N times in a row, should have on average a probability of
> 2^(-N).

I agree with that as long as DoSomething exists with error quickly
in case of a cancellation, so that we can be sure that the context
is still active at the beginning of the select statement.

So this example is correct.

But would you agree that additional checking is necessary if
DoSomething does not have a ctx argument?

Regards,
Torsten.

-- 
Torsten Bronger

-- 
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/874jtrlih4.fsf%40physik.rwth-aachen.de.

[go-nuts] Re: Context cancellation: Is it sufficient to make long-running things interruptible?

[Torsten Bronger]

Hallöchen!

Harris, Andrew writes:

> The precise ordering of things is a bit non-deterministic at the
> fringe. If precise ordering really matters (maybe for cancelling a
> stream like this, it doesn’t, sometimes it does), a default case in
> the select statement is really useful, and it also matters what
> DoSomething does.

But the problem is not that the select statement may block – and
only then a “default” would change anything.  On the contrary, if
the select blocks, I can be sure it detects a cancellation timely.

Regards,
Torsten.

-- 
Torsten Bronger

-- 
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/878rj3limp.fsf%40physik.rwth-aachen.de.

Re: [go-nuts] Context cancellation: Is it sufficient to make long-running things interruptible?

[Harris, Andrew]

The precise ordering of things is a bit non-deterministic at the fringe. If 
precise ordering really matters (maybe for cancelling a stream like this, it 
doesn’t, sometimes it does), a default case in the select statement is really 
useful, and it also matters what DoSomething does.

From: golang-nuts@googlegroups.com  on behalf of 
Torsten Bronger 
Sent: Monday, December 19, 2022 1:52:36 AM
To: golang-nuts@googlegroups.com 
Subject: [go-nuts] Context cancellation: Is it sufficient to make long-running 
things interruptible?

Hallöchen!

The context documentation gives this example:

// Stream generates values with DoSomething and sends them to out
// until DoSomething returns an error or ctx.Done is closed.
func Stream(ctx context.Context, out chan<- Value) error {
for {
v, err := DoSomething(ctx)
if err != nil {
return err
}
select {
case <-ctx.Done():
return ctx.Err()
case out <- v:
}
}
}

What if the channel “out” is drained very efficiently?  Then, an
arbitrary number of loop iterations could happen before a
cancellation is detected, couldn’t it?

I would additionally check for ctx.Err() != nil somewhere in the
loop.  Or is there a reason why this is not necessary?

Regards,
Torsten.

--
Torsten Bronger

--
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/87zgbj7maj.fsf%40physik.rwth-aachen.de.

-- 
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/CO2PR07MB2583C50EEB5E02993AE86792A0E59%40CO2PR07MB2583.namprd07.prod.outlook.com.

[go-nuts] Re: Context cancellation: Is it sufficient to make long-running things interruptible?

[Brian Candler]

On Monday, 19 December 2022 at 10:01:41 UTC Torsten Bronger wrote:

> I would additionally check for ctx.Err() != nil somewhere in the 
> loop. Or is there a reason why this is not necessary?
>

See https://pkg.go.dev/context#Context

// If Done is not yet closed, Err returns nil.
// If Done is closed, Err returns a non-nil error explaining why:
// Canceled if the context was canceled
// or DeadlineExceeded if the context's deadline passed.
// After Err returns a non-nil error, successive calls to Err return 
the same error.
Err() error

Therefore, it's impossible for ctx.Err() != nil unless ctx.Done() is closed 
- and the loop is already checking for this.

-- 
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/eb1149f1-cf5f-4b3f-90a1-d183d212784cn%40googlegroups.com.

Re: [go-nuts] Context cancellation: Is it sufficient to make long-running things interruptible?

[Jan Mercl]

On Mon, Dec 19, 2022 at 11:01 AM Torsten Bronger
 wrote:

> The context documentation gives this example:
>
> // Stream generates values with DoSomething and sends them to out
> // until DoSomething returns an error or ctx.Done is closed.
> func Stream(ctx context.Context, out chan<- Value) error {
> for {
> v, err := DoSomething(ctx)
> if err != nil {
> return err
> }
> select {
> case <-ctx.Done():
> return ctx.Err()
> case out <- v:
> }
> }
> }
>
> What if the channel “out” is drained very efficiently?  Then, an
> arbitrary number of loop iterations could happen before a
> cancellation is detected, couldn’t it?

>From https://go.dev/ref/spec#Select_statements


2. If one or more of the communications can proceed, a single one that
can proceed is chosen via a uniform pseudo-random selection.


Selecting the send case in the above code, when both cases can
proceed, for N times in a row, should have on average a probability of
2^(-N).

-j

-- 
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-WRAxoBXU9xb3DhmG%3DxcPr0%3DcxdjwX8gq%2B_%3Dwb_OS443A%40mail.gmail.com.

[go-nuts] Context cancellation: Is it sufficient to make long-running things interruptible?

[Torsten Bronger]

Hallöchen!

The context documentation gives this example:

// Stream generates values with DoSomething and sends them to out
// until DoSomething returns an error or ctx.Done is closed.
func Stream(ctx context.Context, out chan<- Value) error {
for {
v, err := DoSomething(ctx)
if err != nil {
return err
}
select {
case <-ctx.Done():
return ctx.Err()
case out <- v:
}
}
}

What if the channel “out” is drained very efficiently?  Then, an
arbitrary number of loop iterations could happen before a
cancellation is detected, couldn’t it?

I would additionally check for ctx.Err() != nil somewhere in the
loop.  Or is there a reason why this is not necessary?

Regards,
Torsten.

-- 
Torsten Bronger

-- 
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/87zgbj7maj.fsf%40physik.rwth-aachen.de.