Thanks, now I understand the concerns better. For Linux I stay with my
remark, if you get an error from dup2 nothing has happened. But this is not
true for POSIX, which requires the error of the close to be reported. Linux
doesn't do it, if you look carefully at the code that I have sent, the
result of the close is ignored.
if (tofree)
filp_close(tofree, files);
So I have to withdraw my remark that handling EINTR can do no harm, it
actually can on a system that follows the POSIX specification, because
POSX.1-2013 allows the status of the file descriptor to be undefined after
a close. So the correct behavior for EINTR handling of dup2 and close is
to report it back to the caller. On existing Linux kernels EINTR will
however never be returned by dup2. The Python people got it right
On Saturday, February 29, 2020 at 11:39:48 PM UTC+1, Philip Boampong wrote:
>
> > If you are getting an error nothing has happened, no replacement of
> newfd and no close
>
> I wish that sentence was written on the man page.
> That was the way I first understood it too (and it makes more sense)
> but the little information I found disagree (libuv [1], python [2]
> (see the note about dup2)).
>
> The man page says that "The steps of closing and reusing the file
> descriptor newfd are performed atomically", but it is possible that
> such sentence is only meant to imply that newfd is never reusable
> during the syscall.
> I'm not comfortable accepting your interpretation of "atomic" when
> there is no clear reference and the python implementation disagree;
> that's why I'm asking for more evidence.
>
> [1] https://github.com/libuv/libuv/issues/462
> [2] https://www.python.org/dev/peps/pep-0475/
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/04916e71-c59f-44e6-aca4-cdf70efd13ab%40googlegroups.com.
