Third-party libraries [LWN.net]

Third-party libraries

Posted Aug 27, 2009 21:51 UTC (Thu) by giraffedata (subscriber, #1954)
In reply to: Third-party libraries by quotemstr
Parent article: In brief

I don't see it. Never mind pthread_atfork() -- after all, the issue is exec, not fork. The alternative to O_CLOEXEC for a library that opens files under the covers would seem to be a prepare_for_exec() function exported by the library. The user makes sure he calls that before any exec().

As for the multithreaded program, it already has to serialize access to these file-descriptor-using functions anyway (you wouldn't want two threads opening that file at the same time), so it might as well synchronize prepare_for_exec() with those. This serialization could be done either in the library (i.e. the library is thread-safe), or outside. Oh, and here comes pthread_atfork(): it can make sure the serialization mechanism survives a fork that may precede the exec.

(Log in to post comments)

Third-party libraries

Posted Aug 27, 2009 22:54 UTC (Thu) by Los__D (guest, #15263) [Link]

Besides "prepare_for_exec()" being a horrible interface, do you really think that programmers that doesn't care to close unknown fds, would care to call it?

Third-party libraries

Posted Aug 28, 2009 1:44 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

Besides "prepare_for_exec()" being a horrible interface, do you really think that programmers that doesn't care to close unknown fds, would care to call it?

That's beside the point. I was responding to a claim that there is no way to write a correct multithread program involving a third party library that opens files without O_CLOEXEC. And that that distinguishes O_CLOEXEC from the proposed O_NOSTD.

If on the other hand you just want to argue that O_CLOEXEC is convenient, with or without threads, then you're putting it in the same class as O_NOSTD.

Third-party libraries

Posted Aug 28, 2009 5:39 UTC (Fri) by Los__D (guest, #15263) [Link]

There is no other way for the library author to make sure that his library opened fds are safe.

It is hardly "convenience", but good library programming style, to make sure that internal data stays internal.

I would go so far as argue, that the naïve library user that doesn't close the fds, isn't entirely an idiot for expecting not to be responsible for library data.

Third-party libraries

Posted Aug 27, 2009 23:10 UTC (Thu) by quotemstr (subscriber, #45331) [Link]

Or you just do this (error checks omitted):

#include <pthread.h>

static int fd = -1;
static pthread_mutex_t fd_lock = PTHREAD_MUTEX_INITIALIZER;

static void mylib_beforefork() {
    pthread_mutex_lock(&fd_lock);
}

static void mylib_afterfork() {
    pthread_mutex_unlock(&fd_lock);
}

void mylib_dosomething() {
    pthread_mutex_lock(&fd_lock);
    if(fd == -1) {
        pthread_atfork(mylib_beforefork, 
                       mylib_afterfork, 
                       mylib_afterfork);
        fd = open(...);
        fcntl(fd, F_SETFD, O_CLOEXEC);
    }
    pthread_mutex_unlock(&fd_lock);

    do_something(fd);
}