Re: Per-descriptor state

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>> 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		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B