On Mon, May 16, 2011 at 12:27 AM, Thor Lancelot Simon <[email protected]> wrote: > 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?
How about adding fcntl(F_GETPEER) returning pid_t, then you can do kill(fcntl(fd, F_GETPEER))? Masao > > Thor >
