On Wed, Sep 21, 2011 at 09:58:21AM -0700, Tim Pepper wrote: > The sourceforge.net link above includes a number of suggested options. > And there's also just the simple implementation option for > get_clock() that doesn't have the fd as static much less TLS and > opens/closes at each invocation. That maybe comes with a noticable > performance hit for some types of users and I don't really know the > full list of possible use cases here...do some people really need that > high performance uuid generation? Either way, the "right" general > solution isn't immediately obvious to me so I thought I'd see what > others here thought... Part of the problem is that the uuid library was originally designed non-thread-using libraries, and I originally was trying to force all programs to link against -lpthread. (Remember, libuuid as found in e2fsprogs predates Linux having a standardized threads support, or any threads support at all.) Personally, I think threads are evil, and avoid them like the plague, so I'm not up on the latest threads requirements, but at least at one point, if a shared library used threads all of the programs that called said shared library had to link against pthreads and #include pthread.h, and have errno redefined, etc. (Remember we need to worry about making things work both for the static and shared linking case.) So the reason why I put in THREAD_LOCAL was it was the simplest way to avoid problems without having access to mutexes and without having to drag in the whole posix threads mess and inflicting it on all of libuuid's callers. Unfortunately, it didn't occur to me that people would write programs where they spawned jillions of threads and then abandon them, causing the fd leak that would eventually kill the program. (See my belief that Posix Threads are evil.) 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. - Ted -- 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
