Re: Per-descriptor state

[David Holland <dholland-tech%netbsd.org@localhost>]

On Fri, May 05, 2023 at 09:44:25PM -0400, Mouse wrote:
 > >>> But I kind of think it'd be preferable to make a way to clone a
 > >>> second independent struct file for the same socket than to start
 > >>> mucking with per-descriptor state.
 > >> [...] it should be easy to extend dup3() to make that possible [...]
 > > If we were to add such a thing it should be called something else,
 > > not dup, because it's a fundamentally different operation from dup
 > > and we don't need people confusing them.
 > 
 > Different?  Some.  But not very.  It _is_ closely related to dup().  I
 > don't think dup3() would be a horrible way to do it - 

There's already a dup3(). But ignoring that... yes, it's quite
significant, it constructs a materially different kind of additional
reference. For everyone who knows the internal structure of
references, which is probably everyone reading this list, it's easy to
understand what the semantics are and what the difference between the
two operations; for everyone else, which is most of the world and most
of the people who will ever use the call, it is _not_ clear and if
the two cases aren't made overtly distinct they'll routinely mix them
up and get in trouble. Even if they are made overtly distinct you'll
still get bozos making wrong proclamations about them in places like
stackoverflow.

*puts on his "taught this to undergrads for many years" hat*

 > not nearly as
 > horrible as, say, the hack I once implemented where calling
 > wait4(0x456d756c,(int *)0x61746f72,0x4d616769,(struct rusage *)0x633a2d29)
                                                                          ^^
 > would produce suitably magic effects.  (This was on a 32-bit machine.)

surely you mean 39!

 > But, honestly, when I saw the idea my reaction was to make it a new
 > operation to fcntl.  F_REOPEN, say, since it's creating new per-open
 > state.  Or, if you want to be all overloady, how about
 > open(0,O_REOPEN,existingfd)?  It _is_ creating new per-open state, so
 > open is in _some_ sense right.
 > 
 > My choice, for what it's worth, would be fcntl, dup3 second, with
 > O_REOPEN a distant third.

fcntl is inherently terrible and shouldn't get new ops or use cases
(there is absolutely no reason to prefer it to a new syscall except
for conservation of syscall numbers, which isn't a useful thing).

Should be something like reopen(fd, flags).

Or it could be open("/dev/fd/%d", flags); except that neither the
pathname nor the semantics of /dev/fd are reliably portable.


(...passing a fd as a 3rd argument to open is really horrible; that's
a mode_t, not a fd)

-- 
David A. Holland
dholland%netbsd.org@localhost