Thanks for the fantastic explanation folks.
I wonder if I can ask advice on how to improve my use case. I have a
struct type that represents a state machine and each state is handled by a
different method on that type, each with the same signature I use a
function variable to represent the cu
Hi,
In the below code example, setting a function variable to a simple function
makes no memory allocation and is very fast (<1ns). The case of setting
the same function variable to a method value is much slower (~30ns) and it
turns out to be because memory is allocated there. (16 B/op)
I fou
On Friday, March 3, 2017 at 9:47:35 PM UTC, Igor Gatis wrote:
>
> Or, is there any recommended early replacement?
>
It's being worked on:
https://github.com/golang/go/issues/9671#issuecomment-282091772
It looks like Adam Langley will be working on it too during the 1.9 cycle,
judging by a com
Hi,
I began to find it strange that most potentially blocking operations across
the network for Dial, various http, sql and other things support
context.Context, but basic Read() and Write on net.Conn do not.
Instead they support a trick of setting the read or write deadlines to the
past once
> With plain TCP, a client write followed by a server read and finally a
> client read results in the client getting a "connection reset" error. This
> is expected and reflects the RST seen in a TCP packet as can be seen using
> tcpdump.
>
Correction: I meant to say "a client write followed
Hi,
I noticed a difference in how errors can be returned between a plain TCP
connection and a TLS connection.
With plain TCP, a client write followed by a server read and finally a
client read results in the client getting a "connection reset" error. This
is expected and reflects the RST seen
