[go-nuts] panic: nil dereference in autogenerated hash function

I'm seeing the following panic on both Go 1.20.7 and Go 1.21.0 (amd64): panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x46e421] goroutine 368 [running]: type:.hash.redacted.com/redacted/redacted.componentKey(0xc

[go-nuts] net.Buffers escapes to heap on WriteTo?

I'm sending strings delimited by CRLF over a socket. As an exercise, I'm trying to do it while minimizing the total number of allocations. I wrote a demo with two implementations, CopyWithTerminatingNewlines1 and CopyWithTerminatingNewlines2, both of which copy lines from a `chan []byte` to an

Re: [External] Re: [go-nuts] channels as trylocks

On Thu, Jul 25, 2019 at 1:44 AM Ian Lance Taylor wrote: > > On Wed, Jul 24, 2019 at 11:24 AM shivaram via golang-nuts > wrote: > > > > Several sources, including this issue comment: > > > > https://github.com/golang/go/issues/27544#issuecomment-419265234 > &g

[go-nuts] channels as trylocks

Several sources, including this issue comment: https://github.com/golang/go/issues/27544#issuecomment-419265234 state that a buffered channel of size 1 can be used as a trylock by select'ing on it with a default case. I was thinking about it and it seemed to me that with such an implementation

Re: [go-nuts] sync/atomic and zero-initialization

, March 11, 2019 at 1:16:04 AM UTC-4, Ian Lance Taylor wrote: > > On Sun, Mar 10, 2019 at 7:54 PM shivaram via golang-nuts > > wrote: > > > > Can users of sync/atomic assume that memory will initially be zeroed? Or > is it necessary for a manual zeroing (using the

[go-nuts] sync/atomic and zero-initialization

Can users of sync/atomic assume that memory will initially be zeroed? Or is it necessary for a manual zeroing (using the atomic store operations) to happen-before any reads? Context: https://github.com/golang/go/issues/5045 has the suggestion that "you shouldn't mix atomic and non-atomic access

Re: [go-nuts] implementation of sync.atomic primitives

a program where the same reads and writes are performed with the sync.atomic primitives, or under a mutex. [1] https://blog.regehr.org/archives/490 [2] https://golang.org/doc/articles/race_detector.html On Tuesday, March 20, 2018 at 3:19:48 PM UTC-4, Ian Lance Taylor wrote: > > On Tue, Mar 2

Re: [go-nuts] implementation of sync.atomic primitives

PM UTC-4, Ian Lance Taylor wrote: > > On Mon, Mar 19, 2018 at 5:46 AM, shivaram via golang-nuts > > wrote: > > > > 2. The property that word-sized values are not subject to > > interleaving/tearing is an implementation detail, rather than a > guarantee of

Re: [go-nuts] implementation of sync.atomic primitives

e not subject to interleaving/tearing is an implementation detail, rather than a guarantee of the Go memory model? On Monday, March 19, 2018 at 1:55:07 AM UTC-4, Ian Lance Taylor wrote: > > On Sun, Mar 18, 2018 at 9:47 PM, shivaram via golang-nuts > > wrote: > > > > I

[go-nuts] implementation of sync.atomic primitives

I noticed that internally, the language implementation seems to rely on the atomicity of reads to single-word values: https://github.com/golang/go/blob/bd859439e72a0c48c64259f7de9f175aae3b9c37/src/runtime/chan.go#L160 As I understand it, this atomicity is provided by the cache coherence algorit

[go-nuts] Re: net: unclear how to confirm synchronously that a net.TCPListener is closed

On Tuesday, September 12, 2017 at 1:35:43 AM UTC-4, Dave Cheney wrote: > > > > On Tuesday, 12 September 2017 15:23:56 UTC+10, Shivaram Lingamneni wrote: >> >> So this proves it: "happens-after Listener.Close()" is not a sufficient >> condition for bein

[go-nuts] Re: net: unclear how to confirm synchronously that a net.TCPListener is closed

ps://github.com/golang/go/blob/2d69e9e259ec0f5d5fbeb3498fbd9fed135fe869/src/internal/poll/fd_unix.go#L321 > > On Tuesday, 12 September 2017 14:30:54 UTC+10, Shivaram Lingamneni wrote: >> >> >> >> On Tuesday, September 12, 2017 at 12:13:15 AM UTC-4, Dave Cheney wrote: >>> >>> &g

[go-nuts] Re: net: unclear how to confirm synchronously that a net.TCPListener is closed

On Tuesday, September 12, 2017 at 12:13:15 AM UTC-4, Dave Cheney wrote: > > > > On Tuesday, 12 September 2017 13:40:04 UTC+10, Shivaram Lingamneni wrote: >> >> On Monday, September 11, 2017 at 11:17:01 PM UTC-4, Dave Cheney wrote: >>> >>> The already in

[go-nuts] Re: net: unclear how to confirm synchronously that a net.TCPListener is closed

On Monday, September 11, 2017 at 11:17:01 PM UTC-4, Dave Cheney wrote: > > The already in use is probably coming from the TCP stack which waits a > certain time before allowing the address to be reused. However I thought > that the net package already used SO_REUSEADDR to avoid the delay in close

[go-nuts] Re: net: unclear how to confirm synchronously that a net.TCPListener is closed

On Monday, September 11, 2017 at 10:24:39 PM UTC-4, Dave Cheney wrote: > > What about this ? > > https://play.golang.org/p/qmi1MvLBm8 > > I believe this code is incorrect. Here's a demonstration: https://gist.github.com/slingamn/1467b1bafc613aec7ca0276c31a7a37f/revisions The original revision is

[go-nuts] Re: net: unclear how to confirm synchronously that a net.TCPListener is closed

On Monday, September 11, 2017 at 11:36:33 AM UTC-4, James Bardin wrote: > > > Rather than waiting for just the `Listener.Close` call to return, try > waiting for the call to `Listener.Accept()` to return with a non-Temporary > error. That should error as the result of the file descriptor being

[go-nuts] net: unclear how to confirm synchronously that a net.TCPListener is closed

I'm having trouble understanding an aspect of the `Listener` API. Specifically, when using `net.Listen` to bind to an address, how can one close the listener in such a way that the address is guaranteed to be available for binding again? Here's a test case for Go 1.9: https://gist.github.com/slin