Re: Per-descriptor state

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>> 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 - 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.)

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.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B