Ich versuche, eine "crash handler" für eine C OSX Carbon Multithread Anwendung zu installieren. Unter Windows kann ich einfach die einfache und effiziente __try{} __except{} SEH of Windows verwenden, die gut funktioniert. (Hinweis: diese sind unabhängige zu C++ Ausnahmen sind diese untere Ebene C-Konstrukte!)setjmp/signal crash ausnahmebehandlung
Dies ist sehr im Zusammenhang mit einem question I asked on SO previously: und auch zu einer older SO question.
Die Antwort scheint zu sein, eine setjmp() vor jedem Bereich des Codes zu verwenden, dann verwenden Sie einen Signalhandler zu longjmp() zurück, wenn es einen Absturz gab.
Aber Umsetzung davon ist nicht trivial .. wegen Multithreading! Das __try {} __except {} idiom in Windows ist Thread-sicher und funktioniert einfach. Aber anscheinend ist setjmp nicht threadsicher.
Wie würde eine Implementierung aussehen? Ich denke immer, ich muss einige Thread-lokalen Speicher implementieren. Zu Beginn initialisiere ich setjmp und speichere den Umgebungszustand in einen thread-lokalen Puffer, dann müsste der Signal-Handler die Umgebungsdaten wieder finden, indem er in die thread-lokale Region schaut. Weder Google noch SO zeigen jedoch, dass dies die richtige Strategie ist, zumal setjmp() als Thread-unsicher dokumentiert ist. Und würde Threads lokalen Speichers nicht Thread jeden Thread selbst registrieren und Speicher zuweisen (um diese Umgebungsdaten zu halten), und es bei der Thread-Zerstörung freigeben?
Ich hoffe, ich kann ein Makro machen, das alles so auf OSX wickeln wird, mein __try __except Code wird einfach funktionieren.
Also, wie mache ich einen OSX multithread-sicheren Crash Recovery Handler mit Signalen und setjmp?