>>> 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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B