> -----Original Message----- > From: Robert Elz <[email protected]> > Sent: Monday, January 13, 2020 1:43 PM > To: Schwarz, Konrad (CT RDA IOT SES-DE) <[email protected]> > Cc: [email protected]; [email protected] > Subject: Re: system() and pthread_atfork() > > Date: Mon, 13 Jan 2020 10:13:04 +0000 > From: "Schwarz, Konrad" <mailto:[email protected]> > Message-ID: > <mailto: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. > > [DHCP is allowed to dynamically change addresses]
Captain Obvious here: A minimal quality of implementation attribute for DHCP daemons is for these addresses to remain fixed for as long as possible. Cf. https://kb.isc.org/docs/isc-dhcp-44-manual-pages-dhcpdleases, which is designed to persist address assignments across restarts, e.g., because the hosting server needs to reboot. Or are you suggesting applications must be (re-)coded such that they are resistant to dynamic changes of IP addresses? > 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. The point I was trying to make with the text you did not quote is that if the OP had been more judicious in closing sockets/file descriptors, he would not have run into the problem in the first place. This seriously undermines the case for an all new F_CLOFORK flag and associated paraphernalia. Indeed, except for Solaris, no implementation has ever implemented this, presumably because there is no real-world need for it.
smime.p7s
Description: S/MIME cryptographic signature
