You don't even need to run `go clean`. Go will automatically detect whether
stuff needs to be rebuilt, as the Go version used to build a package is
part of a hash, that is used as a key for the build cache.
And yes, it will use the standard library packages of the Go version that
is installed (the
Say I install golang 1.20.12 and go clean -cache and go clean -modcache.
Then I build.
Will that executable be using crypto/tls and other packages "as they were
in 1.20.12"? Or is golang fetching the newest available compatible sources,
and therefore I may be spinning my wheels trying to see
I tried go1.21.6 and see the same behavior. I'm going to try to backport
the project to go1.18 to see what happens.
On Wednesday, January 10, 2024 at 3:51:16 PM UTC-8 Andrew Athan wrote:
> As you can see in the below output from pprof, the golang TLS
> implementation seems to be in some kind
As you can see in the below output from pprof, the golang TLS
implementation seems to be in some kind of tight loop in
crypto/internal/bigmod.addMulVVW2048 causing CPU starvation, wherein the
net.HTTP server stops calling my request handler. Eventually the TLS
handshakes fail, and the
How do I listen on all* local / loopback* ipv4 /ipv6 interfaces?
net.Listen('tcp', ':') listens on all interfaces. For my application
(oauth token listener) I only want to listen to local / loopback
go doc Net.listen:
* if the host in the address parameter is empty or a literal
On Monday, January 8, 2024 at 7:24:27 AM UTC-8 Michael Knyszek wrote:
On Sun, Jan 7, 2024 at 9:06 PM 'Zhihui Jiang' via golang-nuts <
golan...@googlegroups.com> wrote:
Hi Micheal,
Sorry about delayed response! Please see my replies inline below.
On Wednesday, December 6, 2023 at 8:22:34 PM
> accessing it after munmap leads to SIGSEGV or worse
There must be a hundred different ways you can make a Go program segfault,
and this doesn't sound any worse that the rest of them.
Besides, unless the GC is changed to handle mmap regions differently, I
think you would have the problem the
Hi,
Packages offering memory mapped files in golang follow one of the two
possible routes:
1) memory is accessed via io.Reader (e.g. golang.org/x/exp/mmap);
2) mapped memory is directly exposed as []byte; accessing it after munmap
leads to SIGSEGV or worse (e.g. github.com/edsrzf/mmap-go).
