Proposal: killpeer(2)

[Thor Lancelot Simon <tls%panix.com@localhost>]

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?

Thor