Signals vs Calls

[Havoc Pennington]

On Sun, 2004-10-24 at 18:41 -0700, wink saville wrote:
> Soooooo, dbus looks quite interesting and it does support asynchronous
> messages (signals) but it doesn't seem to be the primary focus. It would
> seem that the developers of dbus feel synchronous messages are better where
> as I've concluded the opposite. Obviously there isn't a correct answer it
> more a matter of opinion, but I was wondering why the focus on synchronous
> messages?

I'm not sure what you mean by sync vs. async.

What I would mean by that is whether a process blocks waiting for a
reply to the message. For a method call with D-BUS, if you want to get
the reply asynchronously (don't block, read the reply when it arrives);
or just ignore the reply; you can do that. You can also set a "no reply
expected" flag on the outgoing call, which is just a hint that you plan
to ignore the reply, so it doesn't need to be sent.

Signals are notification and their main point is that they are one-to-
many instead of one-to-one. This means that a reply doesn't make sense
(which of the many would reply?), so normally you would not block for
the reply, even if you do choose to block for method calls. But you are
not required to block in the method call case either.

I would caution you that D-BUS is not a generic IPC system nor is it
intended to be. Its purpose is to be very good at the two concrete use-
cases we have in mind (systemwide bus and per-session desktop bus). 
It may *happen* to be good for other things, but it isn't designed or
tested for anything else really.

Havoc