Re: Patch ping

[Ian Lance Taylor <ian at airs dot com>]

Paolo Carlini <pcarlini@suse.de> writes:

> Ian Lance Taylor wrote:
> 
> >It would be easy to add a single instance of the mutex in
> >src/locale_init.cc.  But then code compiled with a newer version of
> >libstdc++ would not work with older versions of libstdc++.so, as there
> >would be an undefined symbol at link time.  Does that count as a bad
> >ABI change?  It would continue to be possible to use code compiled
> >with older versions of libstdc++ with the new libstdc++.so; the older
> >code just wouldn't use the mutex when initializing the cache.
> >
> I think this kind of "incompatibility" *in principle* is possible:
> i.e., the .so number of mainline is 6.0.6 whereas 3.4.0 had 6.0.0
> (http://gcc.gnu.org/onlinedocs/libstdc++/abi.html) and certainly the
> same difficulty is experienced by someone trying to use the 3.4.0 .so
> together with code compiled with the mainline - or 4_0-branch for that
> matter - headers.
> 
> However, I think Benjamin espressed some concerns about symbol exports
> (only one for your approach, right?) I'm not sure whether there are
> specific problems with exporting mutex objects or whether he is
> referring to our more general policy lately of adding exports only if
> really, really, needed.

Well, one option would presumably be to try to find somewhere to stash
the mutex which would not cause an ABI compatibility problem.  For
example, perhaps we could add a new field to locale::_Impl in such a
way that no ABI problem was introduced.  If we could ensure that the
new field was at the end of the structure in memory, then presumably
we would be OK as long as nothing depends on the size of the
structure.  Unfortunately, I see that src/globals_locale.cc does
depend on the size of locale::_Impl, so that won't work.

Or another option would be to borrow an existing mutex, which would
not introduce any new dependencies.  Unfortunately, all the mutexes I
see are file static and can not be referenced.

Or another option would be to eliminate the possible memory leak in
some other way.  The possibility of the memory leak arises because two
threads may call operator() on a __use_cache simultaneously.  When
this happens, it is possible for both threads to test that
__caches[__i] is not set, and for both to set it to a new cache
object.  In a preemptive threading model, the threads could switch
right at the assignment in _M_install_cache, so it seems theoretically
possible for the value stored in _M_caches[__index] to be confused by
a simultaneous assignment from two threads.  I don't see this can be
safely avoided without using a mutex.

So the only options I see are to add a new exported symbol in
libstdc++ (which could be a mutex, or we could, e.g., move
locale::_Impl::_M_install_cache to locale.cc), or to not retain the
caches.

Ian