l...@gnu.org (Ludovic Courtès) writes:
> I looked again at how/whether we could improve thread-local storage
> access, using compiler support (the ‘__thread’ storage class).
I worry a bit about having another build option, that might end up not
used and so bitrotting. Also I wonder, if #1 is always better than the
current implementation of pthread_getspecific, why the implementation of
pthread_getspecific isn't rewritten so that it uses #1 inside. Maybe
the signature of the pthread_getspecific API doesn't allow that.
3-4% is well worth having, though, and it seems (from Ken's response)
that we will definitely have to make sure that the pthread_getspecific
implementation keeps working too. So I think this is a good
direction.
> So #3 is appealing (~8% speedup on ‘gcbench’, ~10% on 30 iterations of
> ‘nboyer’). Unfortunately it’s not generally applicable to libguile
> since libguile may be dlopened (e.g., the XChat-Guile plug-in).
(I presume it's actually the plug-in that gets dlopened, and the plug-in
links to libguile. I also presume that that doesn't make any difference
in practice.)
> The relevant work in ‘wip-tls’:
>
> commit 8346727c49c51a9668f10b507daff62dd889850a
> Author: Ludovic Courtès <l...@gnu.org>
> Date: Fri Oct 2 15:02:52 2009 +0200
>
> Deprecate `scm_mask_ints'.
Is there any replacement, or is this something that there was never any
reason to expose? It would be good for the deprecation comment to say a
bit more to justify the deprecation.
> commit b9619bff4ddff267149e7e869ef3c2bcb9c4f4b4
> Author: Ludovic Courtès <l...@gnu.org>
> Date: Fri Oct 2 15:28:29 2009 +0200
>
> Arrange so that `SCM_I_CURRENT_THREAD' is not accessed outside of
> libguile.
This is great. I recommend writing the NEWS soon too, so as not to
build up a backlog of such items that have been removed from the API.
> commit a24c958689c86ac520b73bc9c6e1c40cfbf6f857
> Author: Ludovic Courtès <l...@gnu.org>
> Date: Fri Oct 2 16:32:34 2009 +0200
>
> Use TLS when available for `SCM_I_CURRENT_THREAD'.
>
> Given the second commit, changing the TLS access model for libguile
> doesn’t change the ABI. Power users can compile Guile with the TLS
> model of their choice, which is nice. ;-)
+ [AC_COMPILE_IFELSE([AC_LANG_PROGRAM([static __thread int tls_integer;],
+ [tls_integer = 123;])],
Since we don't use static for scm_i_current_thread, I guess it would be
a more accurate test not to use static here.
+ pf ("/* Define the 1 if the compiler supports the "
+ "`__thread' storage class. */\n");
s/Define the/Define as/
Regards,
Neil
