[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87bm5yiufy.fsf@xmission.com>
Date: Thu, 06 Dec 2018 08:46:57 -0600
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Florian Weimer <fweimer@...hat.com>
Cc: Jürg Billeter <j@...ron.ch>,
Christian Brauner <christian@...uner.io>,
linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
luto@...nel.org, arnd@...db.de, serge@...lyn.com, jannh@...gle.com,
akpm@...ux-foundation.org, oleg@...hat.com, cyphar@...har.com,
viro@...iv.linux.org.uk, linux-fsdevel@...r.kernel.org,
dancol@...gle.com, timmurray@...gle.com, linux-man@...r.kernel.org,
keescook@...omium.org, tglx@...utronix.de, x86@...nel.org
Subject: Re: [PATCH v4] signal: add taskfd_send_signal() syscall
Florian Weimer <fweimer@...hat.com> writes:
> * Eric W. Biederman:
>
>> Floriam are you seeing a problem with this behavior or the way Christian
>> was describing it?
>
> My hope is that you could use taskfd_send_signal one day to send a
> signal to a process which you *known* (based on how you've written your
> application) should be running and not in a zombie state, and get back
> an error if it has exited.
>
> If you get this error, only then you wait on the process, using the file
> descriptor you have, and run some recovery code.
>
> Wouldn't that be a reasonable approach once we've got task descriptors?
Getting an error back if the target was a zombie does seem reasonable,
as in principle it is an easy thing to notice, and post zombie once the
process has been reaped we definitely get an error back.
I also agree that it sounds like an extension, as changing the default
would violate the princile of least surprise.
Eric
Powered by blists - more mailing lists