An atomic approach for HostClient.MaxConns

[xaionaro]

We need to dynamically change a MaxConns value. So this patch is about safe atomic reading from MaxConns.

[erikdubbelboer]

Can you please add some documentation that MaxConns can be changed using atomic.StoreUint64.

[erikdubbelboer]

Thanks.

[xaionaro]

Thank you!

[xaionaro]

is this maybe uint32 better for it can run on i386 system not support x64？

Sounds reasonable to me. I doubt that somebody can reach limit of 4M connections. nf_conntrack will hang much earlier :)

@erikdubbelboer
Should I prepare the (micro-)fix?

[erikdubbelboer]

@xuecai yes for atomic operations it should definitely be a uint32. See: https://golang.org/pkg/sync/atomic/#pkg-note-BUG

[erikdubbelboer]

@xaionaro I'm sorry I made a mistake merging this pull request (looks like I wasn't thinking).
I have fixed it in: e722d81

One problem was that we can't just change HostClient.MaxConns from an int to a uint64. This breaks everyone's code that sets it using something else than a constant.
Another problem was indeed the atomic operations on an uint64.

[xaionaro]

@erikdubbelboer I see. It's quite bad for us. How can we safely change the MaxConns then?

[erikdubbelboer]

@xaionaro that's why I introduced the HostClient.SetMaxConns(newMaxConns) function.

[xaionaro]

@xaionaro that's why I introduced the HostClient.SetMaxConns(newMaxConns) function.

Ah. Did not notice. OK. Thanks. Sorry if I caused any problems :(