I agree with Robert's statement -- this is more of a general problem of
threaded applications and the interactions with fork & threads, which is a
POSIX issue. The networking issue provides an example of one scenario that we
saw a problem with. It could probably be made into a more general case:
1) Application acquires exclusive access to a system resource
2) Application forks
3) Application tries to release & re-acquire access to that resource; there is
a race between the exec() in the child process (releasing the child's access)
and the parent re-acquiring access
Thanks,
Nate
-----Original Message-----
From: Robert Elz <k...@munnari.oz.au>
Sent: Monday, January 13, 2020 6:43 AM
To: Schwarz, Konrad <konrad.schw...@siemens.com>
Cc: Karstens, Nate <nate.karst...@garmin.com>; austin-group-l@opengroup.org
Subject: Re: system() and pthread_atfork()
CAUTION - EXTERNAL EMAIL: Do not click any links or open any attachments unless
you trust the sender and know the content is safe.
Date: Mon, 13 Jan 2020 10:13:04 +0000
From: "Schwarz, Konrad" <konrad.schw...@siemens.com>
Message-ID:
<a45b1767f1002449a37508c2cc6003d7172c9...@defthw99em4msx.ww902.siemens.net>
| I actually feel this problem is out-of-scope for POSIX: compliant machines
| are not supposed to dynamically change their IP addresses at run-time.
I have no idea what (if anything) POSIX says about IP networking requirements,
but I'd expect not much, but that (if it were stated
somewhere) would be an error.
Staticaally assigned IPv4 (or even IPv6) addresses do not tend to change much,
but just about no-one uses those any more.
If you obtain your address (v4 or v6) via DHCP, then when your host goes to
renew the lease, the server can decline, and instruct you (your DHCP client) to
request a new address, at which point it can give out whatever is appropriate,
not necessarily even slightly related to what was there before.
For v6 without DHCP, using stateless autoconfiguration, the router advertises a
(or more than one) local network prefix, with a lifetime, and can alter that
prefix whenever it is required.
One of the real problems with networking in the 80's was dealing with client
networks that needed to be renumbered - the workload for any reasonable sized
network was prohibitive. One of v6's goals was to
defeat that problem (it wasn't only about more addresses). In the
meantime v4 has switched away from static configs (/etc/hosts or the
equivalent) or from BOOTP for hosts without static storage, and to DHCP (where
the 'D' really does mean dynamic) which some v6 sites also use (some odd notion
of the network managers actually being able to control things that way, which
is incorrect, but gives the net admins a warm fuzzy feeling, and it is what
they have become used to with v4).
All that said, I agree that anything related to this issue would be out of
scope for POSIX, but the more general problem of threaded applications (which
it must be, that's the only way that the process can be simultaneously closing
& opening sockets, while also, unknown to itself, also forking)
and the interactions wrt fork & threads, is a POSIX issue. That the
actual problem is networking related is just a side issue, I believe.
kre (IAB member during the period all this network transition started).
________________________________
CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of
the intended recipient(s) and contain information that may be Garmin
confidential and/or Garmin legally privileged. If you have received this email
in error, please notify the sender by reply email and delete the message. Any
disclosure, copying, distribution or use of this communication (including
attachments) by someone other than the intended recipient is prohibited. Thank
you.
