J'ai du code au niveau du système qui déclenche des minuteries de temps en temps, et un gestionnaire de signaux qui gère ces signaux lorsqu'ils arrivent. Cela fonctionne bien et semble tout à fait raisonnable. Il y a également deux threads distincts qui tournent en parallèle du programme principal, mais ils ne partagent aucune variable. Ils utilisent les files d'attente asynchrones de Glib pour transmettre des messages dans un seul sens.
Le même code utilise la fonction GHashTable pour stocker, eh bien, des paires clé/valeur. Lorsque le code de signal est commenté hors du système, la table de hachage semble fonctionner correctement. Cependant, lorsqu'elle est activée, il y a une étrange condition de course où l'appel à g_hash_table_lookup renvoie en fait NULL (ce qui signifie qu'il n'y a pas d'entrée avec la clé utilisée pour la recherche), alors qu'en fait l'entrée est bien là (oui, je m'en suis assuré en imprimant la liste complète des paires clé/valeur avec g_hash_table_foreach ). Pourquoi cela se produit-il la plupart du temps ? L'implémentation de la table de hachage de GLib est-elle boguée ? Parfois, l'appel à la consultation réussit.
Il s'agit d'une situation très particulière, et je peux clarifier davantage si cela n'a pas de sens, mais j'espère que je fais quelque chose de mal pour que cela puisse être corrigé.
Plus d'informations : Les segments de code qui ne sont pas dans la portée du gestionnaire de signaux mais qui accèdent à la variable g_hash_table sont entourés d'appels de blocage de signaux afin que le gestionnaire de signaux n'accède pas à ces variables alors que le processus y accédait également à l'origine.
