Pourquoi shl_load () échouerait-il pour les bibliothèques avec Thread Local Storage?

Question

Les threads en Perl utilisent par défaut leur propre stockage local pour toutes les variables, afin de minimiser l'impact des threads sur le code existant ne tenant pas compte des threads. En Perl, une variable partagée par thread peut être créée en utilisant un attribut:

use threads;
use threads::shared;

my $localvar;
my $sharedvar :shared; 

Le chargeur d'exécution HP-UX ne prend pas en charge le chargement dynamique de bibliothèques partagées contenant le stockage local de threads (TLS).
Par conséquent, lors de la tentative d'importation de modules contenant TLS, l'erreur suivante est signalée:

"/usr/lib/dld.sl: Can't shl_load() a library containing Thread Local Storage"

Alors je sais pourquoi je reçois une erreur. Je ne comprends pas bien pourquoi il serait difficile de charger une bibliothèque avec TLS?

Answer 1

La manière dont le stockage TLS est configuré dépend de l'accès TLS modèle .

Dans la version plus simple, "TLS exécutable / statique initial"; modèle, le chargeur configure le segment TLS avant l'exécution de la première instruction de l'exécutable principal. Il calcule la taille de ce segment en additionnant les exigences TLS de l'exécutable principal et toutes les bibliothèques partagées dont il dépend directement.

Une fois que ce segment TLS est alloué et configuré, l'application commence à s'exécuter et peut stocker des pointeurs dans le segment TLS. Par conséquent, il est impossible de realloc () d’enregistrer le segment - le chargeur n’aurait aucune idée des pointeurs de l’application qui doivent être mis à jour.

Puisque vous ne pouvez pas réaffecter le segment, et qu’il n’ya pas d’espace dans celui-ci pour des variables supplémentaires; comment le chargeur peut-il gérer les bibliothèques chargées de manière dynamique qui nécessitent leur propre stockage TLS?

Le chargeur glibc alloue en fait un espace supplémentaire dans le TLS initial et il peut donc charger dynamiquement des bibliothèques avec TLS, à condition qu'elles n'utilisent pas trop d'espace. Une fois cette réserve épuisée, le chargeur glibc refusera également de charger toute bibliothèque supplémentaire avec les exigences TLS.

Sous Solaris et Linux, il est possible de charger dynamiquement des bibliothèques avec des exigences TLS arbitraires, à l'aide du "General Dynamic TLS modèle ".

Il semblerait que HP-UX v1.6 soit également pris en charge . ce modèle, et en fait en fait le défaut. Mais vous utilisez probablement une version plus ancienne du système d'exploitation, où ce modèle n'est pas le modèle par défaut et peut ne pas être pris en charge du tout. Vérifiez si la version de votre compilateur prend en charge l'option + tls = dynamic et, dans l'affirmative, si la construction avec celle-ci est utile.