Unix FD Passing

[Havoc Pennington]

Hi,

On Fri, May 15, 2009 at 6:54 PM, Lennart Poettering <mzqohf at 0pointer.de> wrote:
>> As we were discussing a bit earlier, I think this may be failing too
>> early. I think it might be better to synthesize an error-reply
>> DBusMessage, similar to what we do if a message times out. That will
>> also mean that things behave consistently if our connection to the bus
>> daemon supports fds, but the other app we're talking to does not, in
>> which case this failure will happen later (inside the bus daemon).
>
> Hmm, what would we do then for the API that deals with preallocated
> messages? Synthesizing a DBusMessage might not be possible on OOM.
>
> So what is more important: that
> dbus_connection_send_preallocated() and dbus_connection_send() work
> the same way or that you get async errors back?

Not sure I'm reading the code properly but it looks to me like we
don't synthesize timeout errors unless you use send_with_reply();
send_preallocated() and send() don't do the client-side synthetic
replies, so you are not guaranteed to ever get a reply at all, while
send_with_reply() guarantees you get a timeout if nothing else. So we
could perhaps copy how timeouts work - only have an error reply if you
use send_with_reply() (or _and_block()). Using plain send(), it would
be as if the remote app didn't reply or was locked up.

That's essentially what you've done here already (only _and_block()
sets a DBusError, right, the others just kind of silently don't send
anything).

Implementation-wise, what this would look like is that we'd silently
fail for the no-reply flavors as you are doing already; and for the
_with_reply flavors (with a DBusPendingCall internally), where we
preallocate a timeout now in the PendingCall, we'd preallocate a "no
fd support" error instead. Change the timeout_link in PendingCall to
error_link or something.

Not sure, but seems like it would usually do as close to the right
thing as possible - error reply or else /dev/null.

Havoc