libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Building shared libraries at configuration time


From: Ludovic Courtès
Subject: Re: Building shared libraries at configuration time
Date: Tue, 01 Jun 2010 18:47:04 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

Hi Bob,

Bob Friesenhahn <address@hidden> writes:

> On Tue, 1 Jun 2010, Ludovic Courtès wrote:
>>> On Tue, 1 Jun 2010, Ludovic Courtès wrote:
>>>
>>>> Hello,
>>>>
>>>> GNU Guile relies on TLS (thread-local storage) support where available,
>>>> and can live without it on inferior systems.  However, I haven’t found a
>>>> reliable way to check whether TLS is supported.
>>>
>>> Why aren't you using the POSIX TLS APIs?
>>
>> Because using __thread allows you to choose a more efficient TLS model
>> without changing your code (see
>> <http://people.redhat.com/drepper/tls.pdf>), and because it requires
>> less initialization-related code.
>
> I can see why this ELF-based TLS extension is attractive (especially
> when updating old code) but it seems wrong for portable software like
> guile to be using it and therefore penalizing standard environments
> which don't support it.  It seems best reserved for OS-specific
> libraries which have no need to be portable.

As I said, Guile has a fallback method for when TLS is not available.
The maintenance cost of having both methods with an #ifdef is actually
low in the case of Guile because there’s currently only one thread-local
variable.  The performance benefit can be noticeable (depending on the
TLS model) because it’s accessed quite often.

Besides, I feel that GNU software should be portable, as it’s always
been, but it should also take advantage of GNU extensions when doing so
doesn’t hinder portability and is beneficial on the GNU system.  It’s
actually the spirit of the GCS (info "(standards) System Portability")
and that of Gnulib, AIUI.

Thanks,
Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]