[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] linux-user: Proper exit code for uncaught signa
From: |
Riku Voipio |
Subject: |
Re: [Qemu-devel] [PATCH] linux-user: Proper exit code for uncaught signals |
Date: |
Thu, 27 Nov 2008 14:44:06 +0200 |
User-agent: |
Mutt/1.5.11+cvs20060126 |
On Thu, Nov 27, 2008 at 12:16:15PM +0000, Jamie Lokier wrote:
> > > The proper exit code for dieing from an uncaught signal is -<signal>.
> > > The kernel doesn't allow exit() or _exit() to pass a negative value.
> > > To get the proper exit code we need to actually die from an uncaught
> > > signal.
>
> It's nothing like -<signal>, so the comment should be changed.
Something like:
Proper exit code for dieing from an uncaught signal differs from normal
exit, so applications using WISIGNALED/WTERMSIG don't get the expected
result. The proper way is to actually die from an uncaught signal.
> The general principle of sending yourself a signal to get the right
> exit status is good.
> > > + sigfillset(&act.sa_mask);
> > > + act.sa_handler = SIG_DFL;
> > > + sigaction(host_sig, &act, NULL);
>
> What if the SIG_DFL _host_ behaviour is not to terminate the host
> process, but it has terminated the guest process? Awkward one.
Could this happen on Linux or is this a portability issue?
> > > + /* For some reason raise(host_sig) doesn't send the signal when
> > > + * statically linked on x86-64. */
> > > + kill(getpid(), host_sig);
> Is getpid() always right here, and should tgkill() or tkill() be used when
> clone is supported?
I'll have to look into this. The thought that this code needs to
do multithreaded signal handling (preferredly in a portable fashion)
feels like I'm heading towards endless swamplands..
--
"rm -rf" only sounds scary if you don't have backups