Hi!
On Wed, Apr 11, 2018 at 10:19:21AM -0700, Ian Lance Taylor wrote:
> You might want to open an issue about this.
Done: https://github.com/golang/go/issues/24808
--
WBR, Alex.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts"
On Wed, Apr 11, 2018 at 7:35 AM, wrote:
>
> 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.
>
Hi!
On Wed, Apr 11, 2018 at 07:35:50AM -0700, pierspowlesl...@gmail.com wrote:
> 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 c
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 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
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!
On Tue, Apr 10, 2018 at 07:58:29AM -0700, pierspowlesl...@gmail.com wrote:
> I'm trying to understand what is going on under the hood here.
SO_LINGER (see socket(7)) delay happens. Add this after Accept():
conn, err := listener.Accept()
if err == nil {
err = c
Your TCP FIN is still in transit or not yet processed by the other TCP
stack when you issue the first write.
TCP is not synchronous even if running on same host.
Janne Snabb
sn...@epipe.com
On 2018-04-10 17:58, pierspowlesl...@gmail.com wrote:
> Hi
>
> I'm trying to understand what is going on
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.
