>>> I should probably add [close-on-fork] here, then, though use cases >>> will likely be rare. I can think of only one program I wrote where >>> it'd be useful; I created a "close these fds post-fork" data >>> structure internally. >> I can't think of any at all; to begin with it's limited to forks >> that don't exec, and unless just using it for convenience as you're >> probably suggesting,
Yes. If the application does all the forking (ie, except for forks inside libraries, for which see below), it is just convenience, freeing the application from keeping track of which fds need closing. Well, except for libraries that open fds internally, without exposing them to the calling code. Depending on the user case, they may want them closed if the application forks. >> it only applies when also using threads, and if one's using threads >> why is one also using forks? Because one wants to exec a child process, maybe? >> So it seems like it's limited to badly designed libraries that want >> to fork behind the caller's back instead of setting up their forks >> at initialization time. Or something. What about libraries that fork _not_ behind the caller's back? (system(3) being, perhaps, the poster child.) > Or it is needed for a little used application called Firefox. What part of "badly designed" does that not fit? (Okay, admittedly, I don't know what Firefox looks like internally. But the UI design is bad enough I would expect the internals to be little better.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
