roadmap

[Havoc Pennington]

Hi,

On Wed, Aug 6, 2008 at 9:14 PM, Scott James Remnant <scott at canonical.com> wrote:
>
> Firstly having it such that an object is notified when somebody is
> matching against its signals, and thus it can choose not to emit them
> unless anybody's listening -- reducing bus wakeup, traffic, etc.  This
> could be handled entirely in bindings.

This was considered when designing the signals stuff. I think there's
a simpler solution, and it happens to have other advantages as well.

The simplest fix, if signal wakeups of the bus daemon are a problem in
a particular case, would be to just have custom methods that
enable/disable signals.

It happens that you commonly want these methods anyway, under the
"register clients" pattern - which btw should be supported by
bindings, Yet Another Binding Feature More Useful Than Object Mapping
- anyway, if you have "register clients" it's easy to only emit
signals when there are clients.

By "register clients" pattern I mean the common case where N processes
register with a server process, and the server process watches for the
N clients to unregister them automatically when they exit, and the
server process calls methods on or emits signals for the benefit of
the N clients.

We could even document some interfaces for that pattern in the spec,
similar to the properties interface, and bindings could support it
generically.

Generically supporting "register clients" in bindings would be great I
think and be a win for reasons above and beyond saving needless signal
emissions.

You often need clients registered anyway for whatever reason (the app
code needs to know about the clients), so if you had a separate
signal-connection mechanism, it would in fact make things less
efficient.

Telling the app about signals is less efficient in any case where the
signal in fact has someone listening to it, because it would be faster
to just assume someone is listening and avoid the setup overhead to
tell the app.

So the (premature, probably) optimization of telling apps what to emit
is only needed when it's a signal nobody cares about anyway. Why not
just not emit it?

A kicker is that this one is probably a pain in the ass to implement
in dbus-daemon. The bus would have to transactionally fail the match
rule setup, waiting on a reply from the emitting client
mid-transaction, or something like that. The bus must be sure the
emitting client has switched on the signal before the bus can return a
reply to the match rule requestor, because there's a race otherwise
(when AddMatch returns we must guarantee that emissions will occur if
state changes). This also makes AddMatch suddenly take
nondeterministic time, i.e. the match-adder is now blocking on a
random app to do something, instead of blocking only on the bus.

Anyway, I think this guy is not worth the trouble. But "register
client" pattern could be.

> I'd also quite like the idea of signal feedback, so the object can know
> whether anybody opted to respond to a signal and find out whether they
> are finished.  Maybe I mean broadcast method calls? :-)
>

If you don't have a "register clients" type of setup, then this can't
work as far as I can see, because you don't know how many reply
messages the object is waiting for before it decides the signal
emission is "done." If you do have a "register clients" setup then
some type of multiple-recipients-for-one-message thing could be an
optimization, maybe one approach is that the reply serial in the
message is used for destination 0, reply_serial+1 for destination 1,
and so forth, so each recipient has its own reply serial. The next
message sent would have serial +N recipients, rather than the usual
+1.

But this is semantically the same as just sending a method call N
times, it's saving N-1 copies of the message as an optimization, but
not adding new semantic power.

It seems like a fine optimization but only if it actually matters for
some real-world performance issue.

I don't think the optimization would be very invasive since it's
basically saying "multiply this method call for me to these N
destinations" and would only change a relatively small amount of code.
I could be wrong.

Havoc