> -----Original Message----- > From: Karstens, Nate <nate.karst...@garmin.com> > Sent: Sunday, January 12, 2020 11:52 AM > To: 'austin-group-l@opengroup.org' <austin-group-l@opengroup.org> > Subject: Re: system() and pthread_atfork()
Going back to the original problem, > We are running Linux on an embedded system. The platform can > change the IP address either according to a proprietary negotiation scheme > or a manual setting. The application uses netlink to listen for IP address > changes; > when this occurs the application closes all of its sockets and re-opens them > using the new address. > > A problem can occur if the application is simultaneously fork/exec-ing a new > process. > The parent process attempts to bind a new socket to a port that it had > previously > bound to (before the IP address change), only to fail because the child > process > continues to hold a socket bound to that port. 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. Even if we accept this premise, I'm not sure I understand the problem: suppose, on the bound socket, you used the specific IP address; then, when switching to the new address, you could simply create a new socket using the new specific address. Since port numbers are local to IP addresses, this should not create a conflict. (The process should close the old socket to conserve file descriptors). On the other hand, if you were using INADDR_ANY, why not simply leave the socket open? I would expect a machine that allows dynamic changes to the supported internet addresses to route new connection requests to pre-existing sockets bound to INADDR_ANY.
