[go-nuts] How to correctly json.Unmarshal struct whose embedded structs define UnmarshalJSON

I want to unmarshal a struct that contains embedded structs: type Parent struct { Child P int } type Child struct { Grandchild C int } type Grandchild struct { G int } The problem is that Grandchild defines its own UnmarshalJSON method, and that means Parent inherits it and breaks json

Re: [go-nuts] Re: Attaching a Finalizer to a struct field holding a slice or the slice's underlying array

Hi John, I'm not sure what I'm about to say (i can't test anything right now), but in your last example, wouldn't it be that the finalizer is never called because the function you give it is a closure that holds a reference of b.Payload itself? Thus the GC would consider b.Payload never unreachabl

[go-nuts] Re: How to correctly json.Unmarshal struct whose embedded structs define UnmarshalJSON

After thinking more about it, I start to feel that maybe using embedded structs is generally a bad idea with dealing with json? Is the correct solution here to use explicit fields? BTW, happy New Year everyone. On Tuesday, December 31, 2019 at 6:21:07 PM UTC+8, Glen Huang wrote: > > I want to u

[go-nuts] Re: net.conn TCP connection

Thanks for all the great responses. How much of the read behavior is in the golang underlying code on the read and how much is on the underlying OS driver that implements the behavior of the read. I understand the stream nature of the TCP connection and I handle that in my code, I was just loo

Re: [go-nuts] Re: net.conn TCP connection

The important factors: 1) the larger the buffer the fewer system calls that need to be made 2) the larger the buffer the more memory use which can be significant with many simultaneous connections You need to remember that with correct socket options the kernel is already buffering, and adding

Re: [go-nuts] Re: net.conn TCP connection

One other note, if you have a request / response type protocol with fairly defined lengths, you don’t need a buffer larger than the largest message if you don’t allow concurrent requests from the same client. > On Dec 31, 2019, at 9:35 AM, Robert Engels wrote: > >  > The important factors: 1

[go-nuts] Re: net.conn TCP connection

\\One other note, if you have a request / response type protocol with fairly defined lengths, you don’t need a buffer larger than the largest message if you don’t allow concurrent requests from the same client. Yes, understood, that was not the constraint, I have to process an unknown amount o

Re: [go-nuts] Re: Attaching a Finalizer to a struct field holding a slice or the slice's underlying array

Hey Michel, In that example, it is indeed the reference to the Payload that causes it not to go out of scope. But you can't print it with the function parameter o, because that is not the slice itself, but the pointer to the first byte of the slice. I would either need a runtime call that remo

Re: [go-nuts] Re: net.conn TCP connection

All of the source is there... but in general it is a bit more complex under the covers than most - as it uses select/poll to know when a socket is ready for IO then schedules the routine in the Read() to perform the IO. So Go has a bit of its own kernel code than you would see in typical synchro

Re: [go-nuts] Re: net.conn TCP connection

Also, you might find something like nats.io simplifies you’re effort. I’m not sure if it supports extremely large message sizes off hand, but there is probably a chunking layer available. Doing simple TCP messaging is fairly easy, when you get into redundancy, fan-out, etc is can get complex fas

[go-nuts] Re: net.conn TCP connection

If you are really interested in how the Go code relates to the underlying socket system calls, the code is readily available. AFAICT, the TCPConn.Read() call *on linux* eventually comes down to the unix version poll.PD.Read(). See https://golang.org/src/internal/poll/fd_unix.go#L145. Before tha

[go-nuts] Mongo Go Models (mgm), MongoDB ODM for Go

Mongo Go Models (mgm) is open-source and makes mongo search and aggregate super easy to do in Golang. It's easy to config Mongo's go driver. All Mongo operators are predefined so you don't have to hard code them. It also has hooks for all the CRUD functions. You

Re: [go-nuts] net.conn TCP connection

So I looked at the implementation of ReadAll, and found this interesting little nugget: if int64(int(capacity)) == capacity {34 buf.Grow(int(capacity))35 } To see it in context: https://golang.org/src/io/ioutil/ioutil.go?s=807:875#L18 Can anybody decipher what

Re: [go-nuts] Re: net.conn TCP connection

On Tue, Dec 31, 2019 at 7:23 AM Ron Wahler wrote: > > How much of the read behavior is in the golang underlying code on the read > and how much is > on the underlying OS driver that implements the behavior of the read. I > understand the stream nature of the TCP connection and I handle that in m

Re: [go-nuts] net.conn TCP connection

On Tue, Dec 31, 2019 at 9:58 AM wrote: > > So I looked at the implementation of ReadAll, and found this interesting > little nugget: > > if int64(int(capacity)) == capacity { > 34 buf.Grow(int(capacity)) > 35 } > > > To see it in context: https://golang.org/src/io/ioutil/ioutil.go?s=8