[Xcb] [PATCH] Open the X11 socket with close-on-exec flag

[Barton C Massey]

In message <a8e2a8e24263604b2d393415344394e7 at chewa.net> you wrote:
On Tue, 16 Feb 2010 12:29:50 +0100, Matthias Hopf <mhopf at suse.de> wrote:
> On Feb 15, 10 16:16:28 -0800, Barton C Massey wrote:
>> > It's a modularity issue. One component opened the X connection;
>> > another called fork(), usually promptly followed by exec(). Then the
>> > child has lost any record that it's sharing an FD with the parent,
>> > unless it goes probing the kernel's FD table.
>>
>> That's what I thought.
>>
>> IMHO this is an application problem, not specific or
>> interesting to XCB, and we shouldn't make it our problem.
>> Just saying.
> 
> A file descriptor is the sole problem of whatever allocated
> it. There is simply no other *sane* responsibility rule in a
> thread-safe environment.  Yeah, library developer like to
> pretend that this is the "application problem". Namely the
> application should have some kind of super mutex whenever
> initializing the library.

Not that.  If the application allocates a resource from a C
library, e.g. by calling xcb_connect(), it should be
prepared to dispose of this resource, e.g. by calling
xcb_disconnect(), at appropriate times.  If the resource
includes a file descriptor, as an xcb_connection most
explicitly does, then the application should know that after
a fork() and before the corresponding exec() is one of those
times.

It's always nice when, as in the case of memory allocations,
this application responsibility can be ignored and the
library or OS will do "the right thing" automatically.  But
file descriptors are persistent across exec() for good
reasons.  I'm not even entirely sure that XCB's behavior of
marking fds CLOEXEC by default is a good idea--I can imagine
situations in which the user might want to turn it back off.
But it seems to be popular, so what the heck.

In other words, application developers like to pretend that
this is the "library problem". Namely the library should
have some kind of super table to keep track of what the
application is doing and magically make the app right behind
its back. :-) :-)

All of that said, whatever people decide is fine by me; I
honestly don't care very much.  Just thought I should get
the cranky old guy perspective out there. :-)  

And honestly, Remi, thanks much for the patch and the
discussion.  Regardless of what is finally decided, the
effort is really appreciated.

    Bart