Re: [go-nuts] Nil pointer panic that should be impossible

hi Axel, is not modifying `u.memoize.str` thread-safe? the len and the data point should become visible at same time? 在2024年3月16日星期六 UTC+8 06:29:06 写道： > Have you tried running the code with the race detector enabled? I suspect > that you are concurrently modifying `u.memoize.str` by calling

Re: [go-nuts] Nil pointer panic that should be impossible

On Thu, Mar 21, 2024 at 2:48 PM 王李荣 wrote: > hi Axel, > > is not modifying `u.memoize.str` thread-safe? the len and the data point > should become visible at same time? > What makes you think that? To be clear, there are no benign data races. Even a data-race on a variable smaller than a word i

Re: [go-nuts] Nil pointer panic that should be impossible

I hadn't used the race detector before. I do see a race warning for (*URL).String() among an embarrassing number of other results. I'm going to update (*URL).String() to use atomic.Pointer to remove the race. Thanks, Ethan On Thu, Mar 21, 2024 at 8:59 AM 'Axel Wagner' via golang-nuts < golang-nut

Re: [go-nuts] io.Reader can return (n, err), both non-zero

+1 I’d love to hear more about the motivation behind the io.EOF as an error. And why select a strategy to prefer *no* *discriminated unions* for the error results? Why transport non-error information in error values (io.EOF, 'http.ErrServerClosed)? “Normal” vs. “error” [control flow] is a fu

Re: [go-nuts] io.Reader can return (n, err), both non-zero

When sending Read() via an RPC call or traversing locks, it is significantly faster to return EOF in the same call as returning the rest of the available data, than to call Read a second time to get the EOF. It's not that hard to handle the EOF semantics. Yes, you have to know what io.EOF means. B

[go-nuts] Discussion on runtime/compiler meeting: Struct packing/reordering

Hello, I have been following the Go Runtime and Compiler team meeting notes for a while. In the recent notes, I noticed something that got my attention regarding memory layout optimization for structures. https://github.com/golang/go/issues/43930#issuecomment-2009816508 I'm working on some cod

Re: [go-nuts] Discussion on runtime/compiler meeting: Struct packing/reordering

‪On Thu, Mar 21, 2024 at 4:47 PM ‫محمد بومنذر‬‎ wrote:‬ > > I have been following the Go Runtime and Compiler team meeting notes for a > while. In the recent notes, I noticed something that got my attention > regarding memory layout optimization for structures. > https://github.com/golang/go/iss

Re: [go-nuts] Nillable basic types?

Hi Axel, Thank you for that link. I had not seen it before, but it is rather insightful. -Mike On Wednesday, March 20, 2024 at 10:29:20 AM UTC-4 Axel Wagner wrote: FWIW I believe (as Brian sort of points out) this proposal is fully subsumed under #57644