ignoring a process' last words: SIGPIPE ...

[Havoc Pennington]

Hi,

On Thu, Mar 27, 2008 at 1:53 PM, Avery Pennarun <apenwarr at gmail.com> wrote:
>  In general, most Internet protocols are designed around this rule by
>  having the client *request* disconnection, and then having the server
>  disconnect only after receiving this request.  That way, neither end
>  is surprised.

Both ends need to deal with the other end crashing or disconnecting. I
would think adding a "clean" way to disconnect just creates another
special case. It's a bug if a "dirty" or "abrupt" disconnect doesn't
work, so the single, only codepath to test may as well be "just close
the socket"

>  In this case, dbus-send is disconnecting without telling the server,
>  and the server doesn't deal well with the surprise.

Which is a bug, even if there is a clean way to disconnect.

>  One perfectly good solution, as proposed already, is to use the
>  --print-reply option to dbus-send, which forces it to stay connected
>  until it gets the answer back.  In fact, this isn't such a bad idea
>  either way.

What I meant on this btw was not to use --print-reply, but make
dbus-send block for reply even if it will not be printing the reply.

The idea of method replies has always been that to reliably send a
method call and know it happened, you need the ack.

>  In the case of dbus-daemon, I'd think it should be safe to just ignore
>  EPIPE and pretend the data has been written.  Remember, the socket
>  isn't really "closed" until you close it, and the fd will remain valid
>  and won't be reused, so there's no reason to throw away any
>  authentication data structures, etc. The socket will close just fine
>  next time through the normal execution path where select() returns
>  true for readable, and then read() returns 0 bytes (EOF).

This may be part of the solution. I would be pretty worried about
introducing bugs, though, if this were not done very carefully. It
would definitely need test cases to be added and all uses of
connection_get_connected(), transport_get_connected(), etc. audited to
see if they "really meant" connected for read or for write. We would
also have to think about possible accidental changes to public API
semantics. I don't know. It seems like it's a lot of work to verify
that this change is OK. Perhaps it is less work than figuring out how
to force immediate read-and-dispatch of remaining incoming messages on
disconnect. But either way is a fair bit of work, unless we just
change it and hope for the best without adding tests or carefully
reviewing the effect on existing API and codepaths.

Havoc