On Wed, Sep 21, 2011 at 1:26 PM, Ted Ts'o <tytso@xxxxxxx> wrote: > It may be that the right answer is to create a separate library which > is used for threading programs --- or develop a completely thread-safe > API for threaded progams, and keep the old API for > sane^H^H^H^Hsingle-threaded programs. I don't think this is so much about API. The documented behavior for uuid_generate() and its siblings does not necessarily need to change here. I view this mostly as an internal implementation detail. The existing code optimizes to reuse the fd and avoids repeated open/close calls for a given caller. If the variables are static, they're not thread safe. So they became thread local. At that point "interesting" threads may become a problem because of the lack of destructor to do closes. But... Is the original optimization really needed? If not you avoid the whole problem...no static, no TLS, no fd left open. And it looks like a similar thing happens in get_random_fd(), fwiw. I wonder who would whinge on performance if the open/close simply happened everytime? Ie: remove initial state_fd=-2 and its associated special casing. Tim -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
