Re: Process Signal Bug On Intel Dual Core Machines?
Re: Process Signal Bug On Intel Dual Core Machines?
- Subject: Re: Process Signal Bug On Intel Dual Core Machines?
- From: Markus Hanauska <email@hidden>
- Date: Thu, 31 Aug 2006 10:58:17 +0200
On 06-08-30, at 23:09, Terry Lambert wrote:
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:
GUI -> Controller Process -> Daemon
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.
--
Best Regards,
Markus Hanauska
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden