Greetings all. This is my first post here and I hope you will all be
kind in light of that.
I need to pose a question of interpretation.
While developing some C code recently, and testing that, I came upon a
VERY surprising and unexpected result. It appears that various flavors
of *NIX are in agreement that after a fork, the set of flag bits (e.g.
O_NONBLOCK) that are associated with any specific file descriptor that
was open prior to the fork will, after the fork, exist only as a single
shared set of flag bits... *not* one copy for the parent and a separate
set for the child.
My reading of both the old and faded hardcopy of the 1993 POSIX API
standard that I have here, as well as the newer draft that Mr. Andrew
Josey was kind enough to point me at today strongly suggest to me that
the implementations I have tested (Linux + FreeBSD) are not conforming
to what is actually on the printed page, either in the 1993 IEEE standard
or in the newer 2018 draft that I am looking at now.
I have come here to solicit opinions on this point.
I have prepared two short example programs exclusively to illustrate the
issue. The first illustrates the issue with respect to ordinary file
descriptors, while the second does so with respect to message queues.
(But the results, when tested against real current implementations, are
identical for both example programs and thus perfectly consistant with
one another, shoing that wether this behavior if confirmant to the standard
or not for both types of descriptors, at least there is consistancy. :-)
These two short example programs may be found at the following links:
https://pastebin.com/raw/AKuWJvyS
https://pastebin.com/raw/KdhKt2Ya
In both cases, the programs end up printing:
O_NONBLOCK magically unset in parent
This occurs in both cases shortly after the recently forked child processes
have expressely and deliberately un-set the O_NONBLOCK flag for a file
descriptor that they have inherited a copy of at the time of the preceeding
fork.
To me, this outcome was beyond surprising, and in conversations with a dear
friend I likened it to the infamous "spooky action at a distance" of quantum
mechanics, which none other than Albert Einstein famously found so troubling.
I am no Einstein by any streatch of the imagination, but like him I also
find this "spooky action at a distance" most disconcerting and also
inexplicable.
How can diddling the flags for one file descriptor cause the flags of a
different file descriptor to magically change also? At the present moment
this still makes no good sense to me, and as I have said, it appears to me
to be inconsistant with the plain language of the standard as written.
I can and will expound upon this point, as may be necessary, but for now
I would prefer to just get some feedback from you folks.
I am fairly thick skinned, so by all means, please feel free to tell me
if you think I'm just crazy, and if in fact the standard does not mean
what it says when it says "The child process shall have its own copy of
the parent's file descriptors."
Thank you all for your attention.
Regards,
rfg
