This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

process exit, dso finalizer, and multiple threads


If a multithreaded application exits while using a DSO (in my case,
libGL), other threads may be executing in code in that DSO when
that DSO's finalizer is executed.  libGL's finalizer needs to free 
resources allocated by libGL.  However, this can cause problems
for threads that are still using these resources.

Is it wrong for the DSO's finalizer to be called while other threads
are executing code in the DSO?  I don't have any spec information
to argue one way or another.  In the case of dlclosing the DSO,
it seems like whoever is dlclosing the DSO should be responsible
for making sure no threads are in or will later enter the DSO.
The case of the exiting process seems more ambiguous, however.

Of course, libGL could synchronize all accesses to libGL such
that the teardown code in the finalizer does not execute until
all threads have exited libGL code, and no threads are allowed to
enter libGL entry points once the finalizer has done its tear down.
While the only solution I can find that is correct, the overhead
of this for all OpenGL entry points is unacceptable for performance.

How do other DSOs deal with this?

Would it be more "correct" for the other threads to be terminated
before the DSO's finalizer is called during process exit?

Thanks,
- Andy Ritger



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]