Re: [go-nuts] Changing channel from unbuffered to buffered prevents goroutine from running

[Ian Lance Taylor]

On Thu, Feb 10, 2022, 9:52 PM Dean Schulze  wrote:

> Here is an exercise using channels and select in a goroutine.  If the
> disconnect channel is changed to a buffered channel the goroutine doesn't
> run at all.
>
> Why does changing from an unbuffered to a buffered channel prevent running
> the goroutine?
>
>
>
>
>
>
>
>
>
>
>
>
>
> * func SelectDemo(wg *sync.WaitGroup) {messageCh :=
> make(chan int, 10)disconnectCh := make(chan struct{})
>   //go routine won't run if channel is buffered
> //disconnectCh := make(chan struct{}, 1)defer
> close(messageCh)defer close(disconnectCh)go func()
> {fmt.Println("  goroutine")
> wg.Add(1)*
>

In order for a WaitGroup to work, you need to call wg.Add before the go
statement, not in the goroutine that it starts.

Ian





>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *for {select {
> case v := <-messageCh:
> fmt.Println(v)case <-disconnectCh:
>   fmt.Println("  disconnectCh")//
>  empty the message channel before exiting
>   for {select {
> case v := <-messageCh:
>   fmt.Println(v)
> default:
> fmt.Println("  disconnection, return")
>   wg.Done()
> return}
> }}}
> }()fmt.Println("Sending ints")for i := 0; i <
> 10; i++ {messageCh <- i}
> fmt.Println("Sending done")disconnectCh <- struct{}{}}*
> Here's the code to call the function from main.  I use the wait group to
> assure that the goroutine completes before the program exits:
>
>
>
> *wg := sync.WaitGroup{}ch09.SelectDemo(&wg)wg.Wait()*
>
> --
> 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/533e6da1-e529-4cd3-a18d-1a4ccf09b947n%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/CAOyqgcWjF5_MVUMh6QgEr%3DmBzCchP%2BUuQx3kEgBi5DPnB3S0jA%40mail.gmail.com.

[go-nuts] Changing channel from unbuffered to buffered prevents goroutine from running

[Dean Schulze]

Here is an exercise using channels and select in a goroutine.  If the 
disconnect channel is changed to a buffered channel the goroutine doesn't 
run at all.

Why does changing from an unbuffered to a buffered channel prevent running 
the goroutine?

   








































* func SelectDemo(wg *sync.WaitGroup) {messageCh := 
make(chan int, 10)disconnectCh := make(chan struct{})  
  //go routine won't run if channel is buffered
//disconnectCh := make(chan struct{}, 1)defer 
close(messageCh)defer close(disconnectCh)go func() 
{fmt.Println("  goroutine")
wg.Add(1)for {select {  
  case v := <-messageCh:
fmt.Println(v)case <-disconnectCh:  
  fmt.Println("  disconnectCh")
//  empty the message channel before exiting
for {select {  
  case v := <-messageCh:
fmt.Println(v)  
  default:
fmt.Println("  disconnection, return")  
  wg.Done()
return}
}}}
}()fmt.Println("Sending ints")for i := 0; i < 
10; i++ {messageCh <- i}
fmt.Println("Sending done")disconnectCh <- struct{}{}}*
Here's the code to call the function from main.  I use the wait group to 
assure that the goroutine completes before the program exits:



*wg := sync.WaitGroup{}ch09.SelectDemo(&wg)wg.Wait()*

-- 
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/533e6da1-e529-4cd3-a18d-1a4ccf09b947n%40googlegroups.com.

[go-nuts] Having trouble getting app to build with Docker after moving to a "src" directory

[David Karr]

I had a small go application building successfully.  I had the go.mod and 
main.go in the root directory of the project, and I was building it pretty 
easily with a Makefile, which just did the following:

CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build -o 
target/dist/linux-amd64

I decided I wanted to move the go source files out of the root dir, so I 
created a "src" directory, then moved "go.*" and my package subdirs to 
"src".  Getting this simple build to work was simple.

I also am constructing a multi-stage Dockerfile, which will be used in the 
CI build. This is a little more complicated, and I'm getting an error on 
the build command that I don't understand.

My Dockerfile looks something like this (... in some places):

--
FROM .../golang:1.17.6-bullseye as go-builder

ARG packages
ARG executable_name
ARG host_src_path
ARG cgo_enabled_01
ARG goos
ARG goarch

COPY $host_src_path .
RUN ls -lt
#RUN go mod download

RUN CGO_ENABLED=$cgo_enabled_01 GOOS=$goos GOARCH=$goarch go build 
-o $executable_name $packages

FROM .../ubuntu-base:20.04

COPY ...
EXPOSE 8080

ENTRYPOINT ...
--

The Docker build looks something like this (... in some places):
-
docker build \
--build-arg host_src_path=src \
--build-arg packages=. \
--build-arg executable_name=... \
--build-arg cgo_enabled_01=1 \
--build-arg goos=linux \
--build-arg goarch=amd64 \
-f Dockerfile -t target/dist/linux/amd64/... .
-

When I run this, I see the following:

Step 10/17 : RUN CGO_ENABLED=$cgo_enabled_01 GOOS=$goos 
GOARCH=$goarch go build -o $executable_name $packages
 ---> Running in 62ef0147061e
$GOPATH/go.mod exists but should not
The command '/bin/sh -c CGO_ENABLED=$cgo_enabled_01 GOOS=$goos 
GOARCH=$goarch go build -o $executable_name $packages' returned a non-zero 
code: 1
make: *** [Makefile:12: dockerbuild] Error 1
---

I googled that error message about go.mod, but I don't understand the 
results, and I don't fully understand how to use GOPATH. I don't remember 
doing anything with it before.

I'm sure I'm operating on some misconceptions, but I'm not sure what I'm 
doing wrong.

-- 
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/484dc24a-18c6-4a7c-84ca-f8acc61c0460n%40googlegroups.com.

[go-nuts] Possible fix to glog's flag-pollition problem

[Gurjeet Singh]

This problem of glog polluting users' options has been reported quite a few
times over the years; for
example, see it reported at golang-nuts mailing list [1], and cue lang
issue [2].

[1]: https://groups.google.com/g/golang-nuts/c/vj8ozVqemnQ
[2]: https://github.com/cue-lang/cue/issues/1199

The problem is that, that glog package registers some flags in its
init() function. The list of registered flags also includes the `-v`
flag, which is usually used by developers either to control verbosity of
their code-execution, or to show the software version. It's notable that
all the complaints are regarding the `-v` flag, and none about the other
flags, since those other flags are unlikely be used by any other
developer.

The proposed fix allows the user of the glog package to change/prefix
glog's flags' names, so that they will not conflict with any flags that
they want to use.

This approach to the problem has a few advantages, compared to other
options like, disabling all the flags in glog.

1. The default behaviour of the glog library is unchanged. So the
current users of the library will not be affected.

2. Any new users who wish to use the -v, or other glog-occupied flag,
can do so at build time.

3. The new users can still use the glog features/flags, albeit with a
prefix.

4. We are not enforcing some specific prefix, which may also conflict.

5. The --help flag, correctly reports the changed/prefixed flag names.

```
$ ./main --help
Usage of ./main:

  ... other glog: prefixed flags ...

  -glog:v value
log level for V logs
  -glog:vmodule value
comma-separated list of pattern=N settings for file-filtered logging
  -v value
Emit verbose execution progress

```

Please also see sample code [3] that demonstrates the problem, and how
the patch fixes the problem.

[3]: https://github.com/gurjeet/glog_fix_test

Best regards,
--
Gurjeet Singh http://gurjeet.singh.im/

-- 
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/CABwTF4WrA4fEyffiN9MDweJiQss8Mcr-7f781yiUSup5cBgqQw%40mail.gmail.com.

[go-nuts] [security] Go 1.17.7 and Go 1.16.14 are released

[Cherry Mui]

Hello gophers,

We have just released Go versions 1.17.7 and 1.16.14, minor point releases.

These minor releases include three security fixes following the security
policy :


   - crypto/elliptic: fix IsOnCurve for big.Int values that are not valid
   coordinates

   Some big.Int values that are not valid field elements (negative or
   overflowing)

   might cause Curve.IsOnCurve to incorrectly return true. Operating on
   those values

   may cause a panic or an invalid curve operation. Note that Unmarshal
   will never
   return such values.

   Thanks to Guido Vranken for reporting this.

   This is CVE-2022-23806 and https://go.dev/issue/50974.



   - math/big: prevent large memory consumption in Rat.SetString

   An attacker can cause unbounded memory growth in a program using
   (*Rat).SetString
   due to an unhandled overflow.

   Thanks to the OSS-Fuzz project for discovering this issue and to
   Emmanuel Odeke
   (@odeke_et) for reporting it.

   This is CVE-2022-23772 and Go issue https://go.dev/issue/50699.



   - cmd/go: prevent branches from materializing into versions

   A branch whose name resembles a version tag (such as "v1.0.0" or
   "subdir/v2.0.0-dev")
   can be considered a valid version by the go command. Materializing
   versions from
   branches might be unexpected and bypass ACLs that limit the creation of
   tags but not
   branches.

   This is CVE-2022-23773 and Go issue https://go.dev/issue/35671.


View the release notes for more information:
https://go.dev/doc/devel/release.html#go1.17.minor

You can download binary and source distributions from the Go web site:
https://go.dev/dl/

To compile from source using a Git clone, update to the release with
"git checkout go1.17.7" and build as usual.

Thanks to everyone who contributed to the releases.

Cheers,
Cherry and Alex for the Go team

-- 
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/CAOW6QtgCdq5HWWOF2WhPF3tiV6b1pHY%2BFb5UGvJHV6aKpd2nmw%40mail.gmail.com.

[go-nuts] Capturing http server TLS handshake error

[Victor]

Is there a way to capture/hook http.Server TLS handshake error?
I mean  overriding/catching the line:
c.server.logf("http: TLS handshake error from %s: %v", c.rwc.RemoteAddr(), 
err)
in /net/http/server.go

-- 
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/7163e4b2-1d68-4916-8903-e8213f82ecafn%40googlegroups.com.

Re: [go-nuts] Re: DataRace with slice, should i fix it or ignore it?

['Dan Kortschak' via golang-nuts]

On Thu, 2022-02-10 at 09:15 -0800, jake...@gmail.com wrote:
>
> On Wednesday, February 9, 2022 at 9:14:52 AM UTC-5 peterGo wrote:
> > Pelen Li,
> >
> > Always fix your data races. You should consider the results of data
> > races as undefined.
> >
> > Dmitry Vyukov, who implemented the Go race detector, once wrote an
> > interesting article with the title: "Benign data races: what could
> > possibly go wrong?"
> >
> > https://twitter.com/dvyukov/status/288858957827682304
>
> This article by Dmitry Vyukov was an "oldie but goodie". I have used
> it as reference in these kinds of discussions before. Unfortunately,
> AFAICT, the article is no longer available on Intel's site. I have
> been unable to locate an alternate location. If anyone knows where I
> can find it, I would appreciate the info.
>


It is on the way back machine
https://web.archive.org/web/20150604005924/http://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong


-- 
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/6e4094beb85981541b805c3635224990a8128c01.camel%40kortschak.io.

Re: [go-nuts] Golang application local timezone doesn't change with the system timezone

[E Z]

I find a way to work around.

The goal is to get the valid timezone of the system periodically in my 
application, So I try to get the valid timezone name from the file 
/etc/timezone and then parse it to the necessary object I need, to avoid 
accessing the file too often, I add a cache for the timezone.  It's not a 
perfect solution, but I think it's enough for my scenario.
On Wednesday, February 9, 2022 at 5:16:28 PM UTC-8 Ian Lance Taylor wrote:

> On Wed, Feb 9, 2022 at 3:37 PM E Z  wrote:
> >
> > I noticed a phenomenon while maintaining my golang application, the 
> local timezone of the application always keep the value when it starts, the 
> local timezone will not change even though I change the system timezone. It 
> looks like the golang time package has been caching the current timezone.
> >
> > Is there any way to change the local timezone in the golang application 
> as the system's timezone changes?
>
> htttps://go.dev/issue/28020
>
> 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/60ac7ee0-8bb0-47c7-9218-91e08397dc57n%40googlegroups.com.

Re: [go-nuts] Re: DataRace with slice, should i fix it or ignore it?

['Dmitry Vyukov' via golang-nuts]

I've recovered it and updated the go/benign-race link.

On Thu, 10 Feb 2022 at 18:35, Ian Lance Taylor  wrote:
>
> [ + dvyukov ]
>
> On Thu, Feb 10, 2022 at 9:16 AM jake...@gmail.com  wrote:
> >
> >
> > On Wednesday, February 9, 2022 at 9:14:52 AM UTC-5 peterGo wrote:
> >>
> >> Pelen Li,
> >>
> >> Always fix your data races. You should consider the results of data races 
> >> as undefined.
> >>
> >> Dmitry Vyukov, who implemented the Go race detector, once wrote an 
> >> interesting article with the title: "Benign data races: what could 
> >> possibly go wrong?"
> >>
> >> https://twitter.com/dvyukov/status/288858957827682304
> >
> >
> > This article by Dmitry Vyukov was an "oldie but goodie". I have used it as 
> > reference in these kinds of discussions before. Unfortunately, AFAICT, the 
> > article is no longer available on Intel's site. I have been unable to 
> > locate an alternate location. If anyone knows where I can find it, I would 
> > appreciate the info.

-- 
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/CACT4Y%2BbWWEHRrK3hvMd0ndSE%3DcdyfhN8gyCYRBfuc6-xJSsSfg%40mail.gmail.com.

Re: [go-nuts] Re: DataRace with slice, should i fix it or ignore it?

[Ian Lance Taylor]

[ + dvyukov ]

On Thu, Feb 10, 2022 at 9:16 AM jake...@gmail.com  wrote:
>
>
> On Wednesday, February 9, 2022 at 9:14:52 AM UTC-5 peterGo wrote:
>>
>> Pelen Li,
>>
>> Always fix your data races. You should consider the results of data races as 
>> undefined.
>>
>> Dmitry Vyukov, who implemented the Go race detector, once wrote an 
>> interesting article with the title: "Benign data races: what could possibly 
>> go wrong?"
>>
>> https://twitter.com/dvyukov/status/288858957827682304
>
>
> This article by Dmitry Vyukov was an "oldie but goodie". I have used it as 
> reference in these kinds of discussions before. Unfortunately, AFAICT, the 
> article is no longer available on Intel's site. I have been unable to locate 
> an alternate location. If anyone knows where I can find it, I would 
> appreciate the info.

-- 
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/CAOyqgcXjR-zP%3Dj7e5CeXCub%2BimKLReswXGR6SKPX9kAzVqXSGg%40mail.gmail.com.

Re: [go-nuts] What exactly can be supplied as "packages" on the go build command line?

[Kurtis Rader]

See `go help packages` and https://go.dev/ref/spec#Packages.

On Thu, Feb 10, 2022 at 9:01 AM David Karr 
wrote:

> When I enter "go help build", the first few lines shows this:
>
>   usage: go build [-o output] [build flags] [packages]
>
>   Build compiles the packages named by the import paths,
>
> The instructions say very little about what can be supplied as "packages".
> It says it can be a list of .go files, and apparently assumes all of the
> supplied files are in a single package , which seems like an odd assumption.
>
> However, I discovered one resource, and from my testing, that just
> supplying "." (period) there also builds the application.
>
> From what I can see, it appears that the basic help information doesn't
> tell the entire story about what can be supplied there, and exactly how
> those values are used.
>
> What are all the legal variations of what can be supplied there, and what
> are the exact semantics of those values?
>
> --
> 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/a6e92bac-e8d6-4cea-b451-a7a1c14af6c3n%40googlegroups.com
> 
> .
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD-_EKHd%3Dzh3O3sTB6nScBeyFkGYTS2cyMMVG_6A7xo-Fw%40mail.gmail.com.

Re: [go-nuts] What exactly can be supplied as "packages" on the go build command line?

[Ian Lance Taylor]

On Thu, Feb 10, 2022 at 9:01 AM David Karr  wrote:
>
> When I enter "go help build", the first few lines shows this:
>
>   usage: go build [-o output] [build flags] [packages]
>
>   Build compiles the packages named by the import paths,
>
> The instructions say very little about what can be supplied as "packages". It 
> says it can be a list of .go files, and apparently assumes all of the 
> supplied files are in a single package , which seems like an odd assumption.
>
> However, I discovered one resource, and from my testing, that just supplying 
> "." (period) there also builds the application.
>
> From what I can see, it appears that the basic help information doesn't tell 
> the entire story about what can be supplied there, and exactly how those 
> values are used.
>
> What are all the legal variations of what can be supplied there, and what are 
> the exact semantics of those values?

See "go help packages" (on the web at
https://pkg.go.dev/cmd/go#hdr-Package_lists_and_patterns).

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/CAOyqgcWW979QhOy9e%2BSVrRcxMv%2BrTwr5YVA4jc%2BFr6H13NJ5Bw%40mail.gmail.com.

[go-nuts] Re: DataRace with slice, should i fix it or ignore it?

[jake...@gmail.com]

On Wednesday, February 9, 2022 at 9:14:52 AM UTC-5 peterGo wrote:

> Pelen Li,
>
> Always fix your data races. You should consider the results of data races 
> as undefined.
>
> Dmitry Vyukov, who implemented the Go race detector, once wrote an 
> interesting article with the title: "Benign data races: what could possibly 
> go wrong?" 
>
> https://twitter.com/dvyukov/status/288858957827682304
>

This article by Dmitry Vyukov was an "oldie but goodie". I have used it as 
reference in these kinds of discussions before. Unfortunately, AFAICT, the 
article is no longer available on Intel's site. I have been unable to 
locate an alternate location. If anyone knows where I can find it, I would 
appreciate the info. 

-- 
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/38cb92a8-38e4-4869-986d-3e0d939d8b47n%40googlegroups.com.

[go-nuts] What exactly can be supplied as "packages" on the go build command line?

[David Karr]

When I enter "go help build", the first few lines shows this:

  usage: go build [-o output] [build flags] [packages]

  Build compiles the packages named by the import paths,

The instructions say very little about what can be supplied as "packages". 
It says it can be a list of .go files, and apparently assumes all of the 
supplied files are in a single package , which seems like an odd assumption.

However, I discovered one resource, and from my testing, that just 
supplying "." (period) there also builds the application.

>From what I can see, it appears that the basic help information doesn't 
tell the entire story about what can be supplied there, and exactly how 
those values are used.

What are all the legal variations of what can be supplied there, and what 
are the exact semantics of those values?

-- 
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/a6e92bac-e8d6-4cea-b451-a7a1c14af6c3n%40googlegroups.com.