Re: Thread-safety "guidelines" of LTDL

[Andreas Mohr]

Hi,

On Wed, Aug 11, 2010 at 03:35:34PM -0500, Bob Friesenhahn wrote:
> Assuming that we agree with most of your points, would it not be  
> sufficient to implement libltdl as a singleton model where each "user"  
> requests a handle, and accesses via this handle access a single actual  
> instance of libltdl in a thread-safe (i.e. mutex protected) way? This 
> approach seems to avoid needing to radically modify libltdl. This 
> approach should also not hinder performance much since dlopen(),  
> dlsym(), and friends already need to include locking in order to be  
> thread safe.

I have to admit I'm unsure how your description differs from my
blathering. Unless you think that it's possible to encapsulate library
access in its entirety via user-faced handles.
There is but one library instance, and access to this single binary
cannot be separated properly unless sufficiently modifying the implementation
itself to provide per-user access, I'd think.

Ah, ok, you would restrict the amount of library modification
to simply using handles for enforcement of internal locking.
However the majority of changes in both cases would be at
the user-facing interface (even when properly getting rid of the entire
static internal data, overall internal changes would be minimal I think).
Thus I don't see why one would resort to using an internal mutex to guard
access, especially since it makes for an ugly contention point
(notwithstanding existing mutexes or potential thread-safety issues
within the inner operating system loader implementations).

> As for myself, I am not at all "threading-resistant" and have yet to see 
> the horrors occur which were forecast by others when I first started to 
> use threading in 1996.  There is no doubt that such horrors are possible 
> absent proper design.

Then you must be one of the lucky guys who are very far from the "anything
goes" mentality that seems to be so rampant in Windows development, I'd say...
(I'd strongly agree with your statement about proper design)

Andreas Mohr