Re: libuuid clock.txt fd leaks

["Ted Ts'o" <tytso@mit.edu>]

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