Subject: question re. dup2.
To: None <email@example.com>
From: Darren Reed <firstname.lastname@example.org>
Date: 06/07/1999 00:08:32
If I have fd's 0,1,2 open, I then set the maximum number of open files
allowed to 0, should dup2(2,1) succeed ?
My first guess is "yes" (as both fd's are already open and allocated), but
upon reading the man page, strictly speaking fd 1 is no longer valid when I
make the dup2 call and hence it should "not" succeed..
Also, can dup2() really return EMFILE if the explanation for EMFILE is
"Too many descriptors are active." ? In the case above, it returns
EBADF, and since the check for EBADF is at the top of sys_dup2(), it
does not appear that NetBSD (1.4) can return EMFILE, ever, for dup2.
Perhaps, if NetBSD were to become threaded in such a way that an fd could
be taken by the same process after the initial checks in sys_dup2() are
complete. Otherwise, I don't see how dup2() can ever return EMFILE.
In light of this, should either the code or man page be changed or left
as-is in waiting for threading which makes these sort of race conditions
possible and hence this error possible ?