J'essaie d'améliorer la portabilité d'une application C++ en utilisant boost: threads à la place de notre propre wrapper sur les threads Win32, et le problème de terminaison de thread gracieux (encore une fois) fait sa tête laide. Sur win32 pur, j'interromps les threads en utilisant QueueUserAPC pour lancer une exception "thread_interrupt" qui provoque le nettoyage de tous les objets RAII en sortie as described here. Toute fonction OS 'alertable' peut être interrompue de cette façon, donc des choses comme les attentes mutex, sleep, serial et socket E/S sont tous des points d'interruption possibles.boost :: threads - comment faire un arrêt gracieux?
Cependant, boost: mutex etc. ne sont pas "alertable" par QueueUserAPC sur win32 - ils appellent des choses comme sommeil (n) plutôt que SleepEx (n, true))
fils de Boost ont une « interruption "mécanisme (qui implique de la même manière de lancer une exception) mais il semble avoir l'inconvénient que SEULMENT les appels boost :: thread sont interrompus, donc une bibliothèque de socket tierce (par exemple) ne peut pas être interrompue.
Que faire? Je pourrais modifier la source d'amplification localement pour la rendre interruptible, mais cela semble être un mauvais choix et je ne pense pas que cela facilite la portabilité. L'application entière REDESSINER pour supprimer l'exigence d'arrêt de fil gracieux est une route ... De la même façon peu attrayante
Je me demandais, qu'est-ce que vous voulez dire par une fermeture gracieuse? Parce que les interruptions sont plus comme une sorte de fermeture très laide si vous me demandez. – KillianDS
@KillianDS - Par fermeture gracieuse, je veux dire que les objets sont détruits correctement à la sortie. Le boost 'interruption' lance une exception pour y parvenir. Un arrêt non-conforme ne détruit pas les objets, ce qui entraînera une fuite de ressources. – Roddy
L'interruption gracieuse de bibliothèques tierces qui ne fournissent pas d'interface pour cela est impossible. – Basilevs