site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Jan 26, 2007, at 6:29 AM, Dave Zarzycki wrote: -- Steve Checkoway _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com On Jan 25, 2007, at 7:25 PM, Steve Checkoway wrote: If it matters, I would only be calling it from within the signal handler which I don't allow to be reentrant. (If another signal happens while I'm in the handler, I give up and just die.) Well, one of our library calls might be in the middle of a Mach based API. :-( I was afraid that might be the case. If that were the case, what would actually happen? Would the later invocation stomp on the suspended one (which would be fine because the app will be killed before the signal handler exits) or is there some shared state that would be in an inconsistent state or would it block waiting for the other code to leave the handler? I am already suspending all other threads using mach apis and that seems to work. At least, I have yet to have a problem with it. I have zero preferences on which api to use to get the job done, so if you can suggest a more suitable one, I'd be more than happy to use it. Why write code at all then? What's wrong with Apple's CrashReporter facility? :-) Two things. One, it hasn't been triggered by that point and two, there're no programatic hooks I know of. smime.p7s