From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <0c048ffc7f81ccf317649882aeea9ea0@felloff.net>
Date: Thu, 13 Nov 2014 13:43:21 +0100
From: cinap_lenrek@felloff.net
To: 9fans@9fans.net
In-Reply-To: <CAGNd-2O+kDrBhzNianMcQQXvTt56y3Osnr1XDauNUxLfNaXKyw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Doesn't 'close' call finish pending 'read' on the same
	'fd'?
Topicbox-Message-UUID: 271db4ca-ead9-11e9-9d60-3106f5b1d025

closing the filedescriptor just removes one reference to the channel
from the descriptor table. the kernels read() function takes its
own reference to the channel to make sure it doesnt go away under it.

the method you describe is a anti-pattern. because the filedescript
(slot) can be reallocated. so even if you close it in the proc, the
fd slot could be reused for somthing different before the other proc
comes arround reading it (or worse, writing it).

what you want is to hangup the tcp connection without fiddling with
the filedescriptor table. this can be done by writing "hangup" to the
connections ctl file like:

int fd, cfd;

fd = dial("tcp!....!123", nil, nil, &cfd);

.....


hangup(cfd);	/* hangup connection, fd stays valid but i/o will error */

--
cinap