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

> 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))?

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.

Reply via email to