Re: [9fans] changing close()
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()
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()
that's a different matter: i was just pointing out that it's still there. ---BeginMessage--- 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---End Message---
Re: [9fans] changing close()
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()
| 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()
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()
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? ---BeginMessage--- 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. ---End Message---
Re: [9fans] changing close()
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()
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
