site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On 06-08-30, at 23:09, Terry Lambert wrote: GUI -> Controller Process -> Daemon -- Best Regards, Markus Hanauska _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... It's still not clear to me whether or not you are running anything from launchd; are you? Okay, I think I got it. I know why SIGTERM is blocked on Intel and not on PPC. Our GUI still runs in Rosetta. When we start the daemon, it is started as follows: Now if we want to kill the daemon, it is like this as well (GUI tells controller to kill, controller sends signal to daemon). The controller and the daemon are not running in Rosetta, they are universal already. The problem is, I assume, Controller Process inherits the signals masks of Rosetta, not of GUI. That would be a Rosetta bug then. It should inherit the mask of the GUI. Since there is no Rosetta on PPC, this is an Intel only issue. By setting all signal settings to the default at the beginning of our daemon, it seems to work again as expected. What I don't understand is why sometimes SIGTERM works on Tiger Intel and sometimes not. Does Rosetta change its signal mask more often? So could it be "random" which signal mask we get when starting the controller? It also does not explain why SIGQUIT won't work (it is not blocked, I made my app print out the whole signal mask and SIGQUIT is not blocked), but since we don't use it anyway, this might be an entirely different bug and should maybe be ignored for this issues. So this is the wrong mailing list then, as Rosetta is not part of the kernel. I'd label it a Rosetta bug and will update the bug report as that. And the SIGQUIT issue should maybe be discussed as an own issue, might not be related to Rosetta at all. So consider this issue as closed on this list. The bug for Rosetta behavior will be #4706151 (this bug also contains more information, like an output of "ps c -O sig,sigmask" and some code and printed signal masks). If I can still reproduce the SIGQUIT issue in the future, I guess I will file an own bug report for that. Thank you for all your help and insight into the signal handling of MacOS X. It was pretty interesting to get all this info. I didn't know many of the system internals on signal processing. This is very valuable information you provided there for future projects. I'm sorry for any trouble you had with this issue. I guess our current application, with a mixture of Rosetta and native processes and with its signal handling way of doing IPC is probably pretty unique, so maybe nobody ever ran into this issue before the way we did. This email sent to site_archiver@lists.apple.com