Perché shl_load () fallirebbe per le librerie con Thread Local Storage?

Question

I thread in Perl per impostazione predefinita prendono la propria memoria locale per tutte le variabili, per ridurre al minimo l'impatto dei thread sul codice esistente non sensibile al thread. In Perl, una variabile condivisa con thread può essere creata usando un attributo:

use threads;
use threads::shared;

my $localvar;
my $sharedvar :shared; 

Il caricatore di runtime HP-UX non supporta il caricamento dinamico di librerie condivise che contengono l'archiviazione locale di thread (TLS).
Di conseguenza, quando si tenta di importare moduli che contengono TLS viene segnalato il seguente errore:

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

Quindi so perché sto ricevendo un errore, non sono ancora chiaro sul motivo per cui sarebbe difficile caricare una libreria con TLS?

Answer 1

Il modo in cui è impostato l'archiviazione TLS dipende dall'accesso TLS modello .

Nel più semplice "eseguibile iniziale / TLS statico" modello, il caricatore imposta il segmento TLS prima dell'esecuzione della prima istruzione dell'eseguibile principale. Calcola la dimensione di quel segmento sommando i requisiti TLS dell'eseguibile principale e di tutte le librerie condivise da cui dipende direttamente.

Dopo aver allocato e impostato questo segmento TLS, l'applicazione inizia a funzionare e può archiviare i puntatori nel segmento TLS. Quindi è impossibile realloc () storage per il segmento - il caricatore non avrebbe idea di quali puntatori nell'applicazione debbano essere aggiornati.

Poiché non è possibile riallocare il segmento e poiché non vi è spazio per ulteriori variabili; come può il caricatore gestire le librerie caricate dinamicamente che richiedono una memoria TLS propria?

Il caricatore glibc alloca effettivamente dello spazio aggiuntivo nel TLS iniziale, quindi può caricare dinamicamente le librerie con TLS, a condizione che non utilizzino troppo spazio. Una volta esaurita questa riserva, il caricatore glibc rifiuterà anche di caricare eventuali librerie aggiuntive con requisiti TLS.

Su Solaris e Linux è possibile caricare dinamicamente librerie con requisiti TLS arbitrari, utilizzando il TLS dinamico generale modello " ;.

Sembra che HP-UX v1.6 anche supporta quel modello, e in effetti lo rende predefinito. Ma probabilmente stai eseguendo una versione del sistema operativo precedente, in cui questo modello non è predefinito e potrebbe non essere supportato affatto. Controlla se la versione del tuo compilatore supporta l'opzione + tls = dynamic e, in tal caso, se la costruzione con esso aiuta.