[9fans] changing close()

[9fans] changing close()

[Ronald G Minnich]

I am wondering about addressing the close() problem, which is that you 
can't close() the send side of a bidi fd without closing the receive 
side too. This has been pointed out as an issue to me w.r.t. TCP sockets 
and such things in which you can't really communicate a zero-byte-write, 
as you could in IL.

BSD hacked around this early (as in 25 years ago) with shutdown(), but
what about having close mode that mirrors open mode:

close(fd) becomes close(fd, ORDWR)

then you can close(fd, OWR) and close(fd, ORD)

Is this a terrible idea? (I'm trying to address the lack of technical 
discussion mentioned  an earlier note :0)

ron

Re: [9fans] changing close()

[Scott Schwartz]

| Is this a terrible idea? (I'm trying to address the lack of technical 
| discussion mentioned  an earlier note :0)

In my humble opinion, the better solution is to have dial return
a pair of descriptors (and change the rest of the system to have
e.g. /net/tcp/9/data{0,1}), so you can close the one you want.

But maybe it's too late for that, and changing close is the only way.

Re: [9fans] changing close()

[Charles Forsyth]

i said that the tcp implementation already had a "hangup" ctl message
>>but that seems to assume that RST sent implies no further data can
>>be received, which might not be right anyway.

but when cooking the duck i remembered that it is right since it's sending RST not FIN.
but a "fin" or "shutdown" message could be added if it really is important.
i'm curious about the applications, though.

Re: [9fans] changing close()

[Derek Fawcus]

On Tue, Aug 16, 2005 at 04:07:04AM -0400, Scott Schwartz wrote:
> | Is this a terrible idea? (I'm trying to address the lack of technical 
> | discussion mentioned  an earlier note :0)
> 
> In my humble opinion, the better solution is to have dial return
> a pair of descriptors (and change the rest of the system to have
> e.g. /net/tcp/9/data{0,1}), so you can close the one you want.
> 
> But maybe it's too late for that, and changing close is the only way.

I fancied having a 'split' call that would act a bit like a collision
between dup and pipe;  it would return 2 fds - a read only and a write
only.   So one could then do:

int bidir_fd;
int unidir_fds[2];

split(bidir_fd, unidir_fds);
close(bidir_fd);

/* Use unidir_fd[0] and unidir_fd[1] */

DF

Re: [9fans] changing close()

[Charles Forsyth]

i wonder if it is common enough to want to change not only close but
9P (Tclunk would presumably change, or another message added such as
T½clunk or Tclink).  i think one reason it wasn't much used in old BSD
is that most TCP/IP protocols have an application handshake at the
end, two exceptions being now-deprecated BSD protocols.  on the other
hand, i grep and see that new BSD manages to use it in cat(!), and why
not, and there are other uses, but only a few could be considered
essential (mainly for those tcp/ip protocols i mentioned).
inessential ones include a few preventing one part of the program
from reading messages written by another part.

still, that's not to say close-write hasn't got some merit if otherwise you
can't do something important, but if its use is generally specific to
particular protocols (applications), one might add a control message
to ip/tcp.c with some consequential coding.  in fact, it has "hangup"
but that seems to assume that RST sent implies no further data can
be received, which might not be right anyway.  perhaps just changing
that would do.  of course, i'm making the assumption
that the application must know these low-level properties, because
application protocol assumes the network has them,
so it won't work on just any type of connection.

it isn't quite the same as with IL/IP because it just transmits write boundaries,
so that as with 9 pipes zero isn't a special case, and it doesn't shut down any
part of the link.

oh. i see. their cat includes specific support for Unix-domain sockets (ifdef'd). what the ...
oh. i see. it's because plain open doesn't work on them and gives EOPNOTSUPP??
not-quite-unix domain sockets?  and there are two shutdown calls but
only one is ever called, on a read-only file, which reduces it to close.
i wondered if some of the other calls i saw are there because a networking book says to use
shutdown.  i saw shutdown(fd, 0); shutdown(fd, 1);
ok, ok. sometimes there are ifdef's and conditionals round some of those, but still.

Re: [9fans] changing close()

[Brantley Coile]

[-- Attachment #1: Type: text/plain, Size: 179 bytes --]

In my version of Unix 7th Edition years ago I added another
svc call to half close anything.  It was a no-op on most files.
I like the Tclink idea.  What about a ½close call?

[-- Attachment #2: Type: message/rfc822, Size: 4193 bytes --]

From: Charles Forsyth <forsyth@terzarima.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] changing close()
Date: Tue, 16 Aug 2005 09:58:13 +0100
Message-ID: <6053acc0f8905c2f30ac5d63f2450019@terzarima.net>

i wonder if it is common enough to want to change not only close but
9P (Tclunk would presumably change, or another message added such as
T½clunk or Tclink).  i think one reason it wasn't much used in old BSD
is that most TCP/IP protocols have an application handshake at the
end, two exceptions being now-deprecated BSD protocols.  on the other
hand, i grep and see that new BSD manages to use it in cat(!), and why
not, and there are other uses, but only a few could be considered
essential (mainly for those tcp/ip protocols i mentioned).
inessential ones include a few preventing one part of the program
from reading messages written by another part.

still, that's not to say close-write hasn't got some merit if otherwise you
can't do something important, but if its use is generally specific to
particular protocols (applications), one might add a control message
to ip/tcp.c with some consequential coding.  in fact, it has "hangup"
but that seems to assume that RST sent implies no further data can
be received, which might not be right anyway.  perhaps just changing
that would do.  of course, i'm making the assumption
that the application must know these low-level properties, because
application protocol assumes the network has them,
so it won't work on just any type of connection.

it isn't quite the same as with IL/IP because it just transmits write boundaries,
so that as with 9 pipes zero isn't a special case, and it doesn't shut down any
part of the link.

oh. i see. their cat includes specific support for Unix-domain sockets (ifdef'd). what the ...
oh. i see. it's because plain open doesn't work on them and gives EOPNOTSUPP??
not-quite-unix domain sockets?  and there are two shutdown calls but
only one is ever called, on a read-only file, which reduces it to close.
i wondered if some of the other calls i saw are there because a networking book says to use
shutdown.  i saw shutdown(fd, 0); shutdown(fd, 1);
ok, ok. sometimes there are ifdef's and conditionals round some of those, but still.

Re: [9fans] changing close()

[Russ Cox]

> Is this a terrible idea?

Yes.  It's TCP-specific and hardly ever necessary.
I thought we'd convinced you last time.

Russ

Re: [9fans] changing close()

[Ronald G Minnich]

Russ Cox wrote:
>>Is this a terrible idea?
> 
> 
> Yes.  It's TCP-specific and hardly ever necessary.
> I thought we'd convinced you last time.

maybe you had.

however, this is a distributed computing system, and something like 100% 
of my usage is over a network. In fact, the single most important thing 
I do with these things is over a network. IL being long gone, all that 
usage is over tcp.

So, yeah, it's tcp specific, but ... so is everything, since everything 
I do is on a network, and all network stuff is tcp.

The fact that we can't do a trivial thing like shutdown one side of a 
socket is kind of a headache, and, yes, it's an infrequent headache, but 
I'm spending too much on tylenol as it is (I work for DOE, after all).

Obviously, I can start buying store-brand drugs, in bulk, but I wanted 
to ask one more time about the other option, removing the occasional 
cause of a headache.

ron

Re: [9fans] changing close()

[Charles Forsyth]

>>IL being long gone, all that 

i use it all the time, even across boundaries.
it seems to work better on my wireless network, too.

Re: [9fans] changing close()

[Ronald G Minnich]

Charles Forsyth wrote:
>>>IL being long gone, all that 
> 
> 
> i use it all the time, even across boundaries.
> it seems to work better on my wireless network, too.
> 
even to systems that have no IL?

ron

Re: [9fans] changing close()

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 78 bytes --]

that's a different matter: i was just pointing out that
it's still there.


[-- Attachment #2: Type: message/rfc822, Size: 2941 bytes --]

From: Ronald G Minnich <rminnich@lanl.gov>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] changing close()
Date: Tue, 23 Aug 2005 03:03:18 -0600
Message-ID: <430AE656.5000302@lanl.gov>

Charles Forsyth wrote:
>>>IL being long gone, all that 
> 
> 
> i use it all the time, even across boundaries.
> it seems to work better on my wireless network, too.
> 
even to systems that have no IL?

ron

Re: [9fans] changing close()

[kokamoto]

>>>IL being long gone, all that 
> 
> i use it all the time, even across boundaries.

I'm doing it too at work.   Geoff's 64bit Ken's fileserver began to work.
Thanks Geoff, it's very nice, I can use long file names there.

Kenji  -- from home

Re: [9fans] changing close()

[kokamoto]

[-- Attachment #1: Type: text/plain, Size: 223 bytes --]

We are here running Fossil+Venti, too.
However, Ken's file server + auth server + terminals Plan 9 system is
the clearest conceptually, and which we need to show our students
concept rather than convenience...

Kenji

[-- Attachment #2: Type: message/rfc822, Size: 3179 bytes --]

From: kokamoto@hera.eonet.ne.jp
To: 9fans@cse.psu.edu
Subject: Re: [9fans] changing close()
Date: Sat, 27 Aug 2005 17:02:37 +0900
Message-ID: <59f6243a5c1ad89ccb793e84a4db84e0@hera.eonet.ne.jp>

>>>IL being long gone, all that 
> 
> i use it all the time, even across boundaries.

I'm doing it too at work.   Geoff's 64bit Ken's fileserver began to work.
Thanks Geoff, it's very nice, I can use long file names there.

Kenji  -- from home