4 ms·
Nah - one would just add a new syscall, to split the fd. int sock_fd, split_pair[2]; char c; int n = socket_split(sock_fd, split_pair); close(s
by dfawcus 3y ago
Nah - one would just add a new syscall, to split the fd.
int sock_fd, split_pair[2];
char c;
int n = socket_split(sock_fd, split_pair);
close(sock_fd);
n = write(split_pair[1], "a", 1);
close(split_pair[1]);
n = read(split_pair[0], &c, 1);
read(split_pair[0], &c, 1); /* returns 0 / EOF */
The effect being to split the fds, and give an output similar to pipe(2). Moreover it would also duplicate the underlying open file structure, such that one is read only, the other write only, and both referencing the same socket. Then the read fd would reference one "open file", the write-fd the other.
(One can observe a similar issue if one opens FIFO's in read/write mode, but since they can also be opened read-only or write-only, the issue does not arise.)
- jerf 3y agoI wonder if perhaps you replied to the wrong comment? I never questioned that it could be done, I was discussing the results from the point of view of it already being done (and for my discussion's purpose, mandatory).
- dfawcus 3y agoI was disagreeing with your first paragraph. If the splitting is optional, as it would have to be now, and as I proposed it would not add complexity since it would be opt in. Theoretically if it had split from the start, it may have added a minor amount of complexity to some programs, but not a significant amount. I don't get the need to add TCP states, as the TCP machine will not change, and the user space app shouldn't really be tracking/replicatting the TCP states. Anyway, your assumed (and mandatory) point of view was not obvious to me, I interpreted it from the position of "if that was done now". Which would add a trivial amount of logic to the kernel, mainly reusing existing logic, structures, and counters. So I guess we were slightly at cross purposes.