Hi all
I've written a simple program which simply sends a message across a tcp
connection and back again.
For some reason when I make the buffer larger than a certain size the
program deadlocks.
When run on the playground with datalen set to 1 the program deadlocks
but with datalen set to
Thanks so much, I had in fact been using buffered readers and writers, for
this test and had removed them to make my example more lean, forgetting
that the read and write methods behave differently to those of net.Conn.
My original problem when using the buffered readers and writers is that I
h
Hi
I'm trying to understand what is going on under the hood here.
I would expect a net.Conn after being closed from the far side, to issue an
error if the near side then tries to write to it. On my local machine an
error is returned on the second write, on the go playground all writes
succeed.
Hi Alex
Thanks for your suggestion, I have implemented it, but something is still
not quite right, the first iteration of the loop to write to the conn still
encounters a temporary error, even though the internal error is a
syscall.ECONNRESET.
Please see the updated code below
func TestRemote
Hi Janne
I don't think that is the problem since the problem persists even after
inserting a 4 second wait between closing the connection from the far side
and writing to the near side.
On Tuesday, April 10, 2018 at 5:02:32 PM UTC+1, Janne Snabb wrote:
>
> Your TCP FIN is still in transit or no
So I believe I have found the source of this problem. A method Temporary is
defined on syscall.Errno, for a reason that is unclear to me ECONNRESET and
ECONNABORTED are considered temporary. I would definitely consider those
errors permanent.
func (e Errno) Temporary() bool {
return e == EINT
Hi there,
I used pprof to get an overview of where time is being spent in my latest
project and I'm
getting a result I don't understand. When using the web view, there are
certain function
calls that are taking up a large percentage of the time but they appear
un-rooted as in
there seems to be
The doc for cgo states ...
"Go code may pass a Go pointer to C provided the Go memory to which it
points does not contain any Go pointers. The C code must preserve this
property: it must not store any Go pointers in Go memory, even temporarily.
When passing a pointer to a field in a struct, the
Thanks for the links Ian, very informative :)
On Monday, January 23, 2017 at 5:43:56 PM UTC, Ian Lance Taylor wrote:
>
> On Mon, Jan 23, 2017 at 3:57 AM, >
> wrote:
> > The doc for cgo states ...
> >
> > "Go code may pass a Go pointer to C provided the Go memory to which it
> > points does n
