3 ms·
> The API could easily have involved two unidirectional fds instead of just one, without changing the protocol, or how easy/difficult it is to establish a conne
by rstuart4133 3y ago
> The API could easily have involved two unidirectional fds instead of just one, without changing the protocol, or how easy/difficult it is to establish a connection.
I can't see how it's an improvement. The pipe code is invariably:
pipe(fds);
close(fd[0]); /* Close the one we don't need. */
If you don't want one direction of a socket the code is:
connect(soc, ...);
shutdown(soc, ...); /* Close the one we don't need. */
Dan's complaint is quote "The BSD socket designers introduced a shutdown(fd,1) system call to send FIN through a TCP connection. This is exactly the sort of device-specific garbage that UNIX fds were designed to avoid." However the code for pipes and sockets near identical bar the names. Just to re-enforce how similar they are, if you don't call "close()" for pipes, his core complaint that nothing exits because "the same fd is still open in the consume-data program" happens in the pipe case.
This makes me think of hobgoblins and minds.
- tonyg 3y agoThe problem is you can't statically know, in e.g. Dan's `generate-data`, which to call: close() or shutdown(). You have to reflect on stdout to discover what kind of resource you have. So there's a downside to the inconsistency. Is there a corresponding upside I'm not seeing? Cause if not, perhaps all else equal, in which case I'd rather have the static simplification.
- rstuart4133 3y ago> The problem is you can't statically know, in e.g. Dan's `generate-data`, which to call: close() or shutdown(). True. But code like this is invariably a 3 step process - setup the invariants, loop (generate-data), then close down. The steps above happen in the open, which means `generate-data` doesn't need to know what to call. The Dan's pipeline gave is a good example of this as any. It is the shell that does the open step, so it's the thing that does the open, so it creates the pipes and does the close() of the unwanted end. Thus Dan `generate-data` does not need to know whether it is sending over s pipe or TCP connection. In fact bash accepts /dev/tcp/host/port syntax. I presume it already does the required shutdown as part of that of setting it up. Which demonstrates that in real life `generate-data` in indeed blissfully unaware of whether it's a pipe or socket. Finally, notice the open step is always going to be different, so this additional work of setting it up different is not a big imposition. It's has to be different because it has to connect the two ends, and that is going to be different depending on whether they are local or remote.