tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Proposal: killpeer(2)
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))?
Masao
>
> Thor
>
Home |
Main Index |
Thread Index |
Old Index