How to avoid client side polling?

[Fan Wu]

Hi,

I'm thinking about using DBUS for our software product which covers
hand-held devices. A major concern we have is about polling on the
client side. Polling frequently drains battery, while polling less
frequently renders the system irresponsive. Note that our processes
interacting with DBUS could be dual-roled: they could be
service-provider and service-consumer at the same time.

If polling is not used at all, the only other option I can think of is
blocking in separate threads. Two threads are needed to cover all
sceanrios and each thread has its own DBUS connection. For service
provider (take requests and generate responses) a thread is needed to
block on incoming data (from DBUS daemon). For signal emitter and
service consumer (generate requests and wait for responses), another
thread is always there waiting for outgoing data. Since the calls are
blocking, only one request can be handled at a time.

We can probably cover all the cases with one DBUS connection and one
thread if the polling is interruptable: the thread is blocking (or
polling with infinite timeout) on incoming data, but this
blocking/polling can be interrupted whenever our application wants to
send something out. The problem with this approach is how to avoid
hard interrupt (like sending a signal) which might introduce
deadlocks. One possible solution (for Unix platforms) is to initialize
the transport layer with one end of an unamed pipe (or socketpair),
and the transport also select() on the unamed pipe. To interrupt the
deep sleep of a select call, all that you need to do is to write
something to the unamed pipe. To implement this "feature" some
internal stuff of DBUS needs to be changed.

Please let me know if you have comments or better solutions.

Thanks,
Fan