Discussion :

[divide]

Bonjour,

À de très rares occasions, sur certaines configurations exotiques mon programme est confronté à des crashs indépendant de mon code, qui sont due soit à un driver audio buggé, soit à un driver OpenGL buggé.
Par exemple c'est arrivé avec le driver audio virtuel DFX Audio Enhancer, et avec un vieux driver AMD de 2010.
Dans ce genre de cas, plutôt qu'un crash brutal avec un message d'erreur système j'aimerai afficher un message à l'utilisateur proposant un diagnostique possible.
Pour ça j'ai trouvé la fonction signal:
http://www.cplusplus.com/reference/csignal/signal/
Qui semble faire parfaitement son office, puisque j'arrive maintenant à intercepter les rares cas qui me posaient problème.

Cependant mon application fait de nombreux calculs en temps réel, et je voudrais être sur que l'interception de ces exceptions ne provoque pas de ralentissement du code en général, c'est à dire que ça n'induit pas un monitoring constant mais juste un déclenchement au moment même de l'exception. Savez vous ce qu'il en est ? Avez vous des infos la dessus ?

Merci !

[bacelar]

J'espère que vous n'utilisez pas cette cochonnerie sur plateforme Windows.
Sinon, il n'y a pas d'overhead lié à cette fonctionnalité car cela se contente de mettre un pointeur dans une table système et d'appeler ce pointeur qu'au moment du signal.

[divide]

Super, merci pour la réponse. Bien que je ne vois pas trop le rapport avec Windows; c'est un programme multiplateforme Windows/OS X, et signal() semble intercepter les exceptions comme il faut sur Windows.

[bacelar]

Signal n'intercepte pas les exceptions.
L'interception remonte vers l'OS, qui, on fonction de sa configuration, utilise une table planquée dans les données système du processus.
Déjà, il y a plus de 20 ans, c'était le foutoir entre les Unix qui n'acceptaient pas la réentrance dans ces handlers et les autres qui se coltinaient un masque de bit pour le blocage temporaire des signaux, signal par signal.

J'espère que ce foutoir c'est un peu résorbé, mais déjà que ces signaux n'ont jamais correctement fonctionnés sous Windows pré-NT, avec le sous-système tarte à la crème de POSIX sous Windows NT (pour notre cher Oncle Sam), c'est le genre de trucs qui ne fonctionnera très probablement que dans ce sous-système des plus anecdotique.

Sous Windows, ce n'est clairement pas solution la plus simple et la plus puissante :
WER
https://msdn.microsoft.com/en-us/lib...=vs.85%29.aspx

[divide]

Ah.. Quoi qu'il en soit, quand je lui fournis un driver foireux qui fait crasher mon application, le signal SIGABRT/SIGILL/SIGSEGV est bien redirigé vers ma fonction prédéfinie, du coup ça fait ce que je voulais. Du moment que ça n'impacte pas les perfs du reste de l'application, ça me va