Re: Proposal: killpeer(2)

[Adam Hamsik <haaaad%gmail.com@localhost>]

On May,Sunday 15 2011, at 6:58 PM, Masao Uebayashi wrote:

> On Mon, May 16, 2011 at 12:27 AM, Thor Lancelot Simon 
> <tls%panix.com@localhost> wrote:
>> On Sat, May 14, 2011 at 04:16:54PM +0200, Emmanuel Dreyfus wrote:
>>> Thor Lancelot Simon <tls%panix.com@localhost> wrote:
>>> 
>>>> What process group does perfused end up in?  Its own?  Otherwise killpg
>>>> might do the trick.
>>> 
>>> perfused is still in the process group of the terminal it was launched.
>>> But glusterfs gets -1, acording to ps -o pid,tpgid,command
>> 
>> I have been thinking about ways to handle this that are general and
>> safe.
>> 
>> The basic problem is that what's really wanted is a way to send a signal
>> to the other process associated with a particular resource, in this case
>> a datagram socket.
>> 
>> This can't really work for a datagram (as opposed to a sequenced-packet)
>> socket because there isn't just one other process -- the mapping can be
>> one to N and of course N can even be zero.  But this just highlights that
>> SOCK_DGRAM isn't quite right for many uses of unix domain sockets anyway.
>> What is really wanted is a connection-oriented, record-based socket.  I
>> am not sure but I think SOCK_SEQPACKET is supposed to be for this kind of
>> thing.
>> 
>> If we had a socket type which was record oriented but cloned on accept()
>> like stream sockets, then we _would_ have a file descriptor per peer and
>> what I'm describing below would work:
>> 
>> Putting that aside for a moment, let's pretend we had a stream socket in
>> this application instead of a datagram one.  I think the right thing to
>> do at that point would be to add a killpeer() syscall, which sends a
>> signal to the other process associated with a file descriptor.  This is
>> reasonably general -- it would be useful for ptys and pipes as well, I
>> think.  I think it would be a very useful tool for cleanup of potentially
>> misbehaving peers in many local-IPC client/server applications.
>> 
>> Opinions?
> 
> How about adding fcntl(F_GETPEER) returning pid_t, then you can do
> kill(fcntl(fd, F_GETPEER))?

What about adding 2 calls F_GETPEER and F_ADDPEER that way process which 
would like to have singals delivered from other side have to call

> fcntl(fd, F_ADDPEER)

Everything else stays same. Signal will be delivered only to pids 
which called ADDPEER (if they exit they need to be removed from peer list).

Regards

Adam.