On Sat, May 14, 2011 at 04:16:54PM +0200, Emmanuel Dreyfus wrote: > Thor Lancelot Simon <[email protected]> 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
