Including the originating PID in every message?

[Havoc Pennington]

Hi,

On Fri, Apr 17, 2009 at 6:12 PM, Havoc Pennington
<havoc.pennington at gmail.com> wrote:
> You can assume that all messages (at least all 4 current message
> types) have a sender field set to the unique bus name of the sender.
> Then as David says you only have to do the round-trip query one time
> per sender, and keep the PID cached. There's no way the PID can change
> for a unique bus name. (It can change for a well-known bus name.)
>

btw, best-practice avoids the round trip in most cases, as follows:

* install a signal match to detect your peer process by well-known
name; see "fourth piece" in
http://mail.gnome.org/archives/gtk-devel-list/2009-February/msg00121.html

* when the peer process comes on the bus, you'll get async
notification of the unique bus name.
At this point, asynchronously fire off your request for its PID and
store DBusPendingCall for the pid request

* if you get an incoming message from the peer process before you get
the pid reply, only then do you need to block on the pending call

* if, more helpfully, you get the PID back before any messages from
the peer, you will never end up blocking

This particular round-trip is probably not worth a lot of pain to
avoid, though, because it only goes to dbus-daemon and not all the way
to some remote app, so it should always be pretty fast and only
involves switching context to a single other process (dbus-daemon).

Havoc