> -----Original Message----- > From: Robert Elz <k...@munnari.oz.au> > Sent: Tuesday, January 14, 2020 11:35 AM > To: Schwarz, Konrad (CT RDA IOT SES-DE) <konrad.schw...@siemens.com> > Cc: nate.karst...@garmin.com; austin-group-l@opengroup.org > Subject: Re: system() and pthread_atfork()
> | 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. > > The issue (as I understand it, I do not like the threading methedology, and > do not use it) is that in threaded > processes, with everything happening in parallel, and no one thread having > any real idea what any other thread > might be doing, there is no way to achieve the result you are expecting. > > That is, at the exact same instant one thread is doing fork() another > is doing open() or socket(). If it happens that the open() finishes one > zeta-second before the fork() starts then the fd from that open will be > inherited by the child of the fork, but > because the thread doing the open has not hat time to save the fd anywhere > yet, there is no way for the child > process (which only contains the thread which forked, not the others, > including not the one that did the open()) > to ever discover what that fd was, or what it connects to. But this is benign. Only one thread is running in the new process, that thread does not touch any sockets it knows nothing about, and it will soon exec(), and the close-on-exit flag will do its job. The mistake the OP was doing is to close the listening socket, which is bound to INADDR_ANY (and a fixed port), in response to an IP address change. When he does this and an unrelated fork() occurs, a race ensures: if the exec() does not happen soon enough, the parent fails to rebind to the socket, because it is still open in the child. Had he simply left the existing listening socket alone, everything would have worked. > > | This seriously undermines the case for an all new F_CLOFORK flag > > If it weren't for threading, I would not support it at all. In any > non-threaded context it is a stupid idea. But I can see the need for > it with our current threading methedology. The real problem is that > threads are a horrid misfeature. Unfortunately, lots of people seem > to like the evil things. No use case demonstrating need for this feature has been presented up to now.
