How to avoid client side polling?

[Fan Wu]

Hi Havoc, Thiago,

Let me rephrase my situation here: I'm trying to provde a DBUS glue to
an application suite which are developed by different teams. For the
ease of dicussion let's pick one and name it Y. Y takes input from
other DBUS applications, while Y's own event model may NOT be
pollable.

I can't let DBUS interaction block the whole application since Y won't
be able to do its own work.

X is both a service provider and service consumer. In other words, in
some cases X takes requests from other DBUS clients and sends back
response. In other cases Y initiates requests to other service
providers in DBUS. So if polling is not used, I think we need to have
two separate connections and two corresponding threads. One thread
blocks on the DBusConnection for incoming requests, and another thread
waits to process outgoing requests.

Or if there is a way to interrupt the blocking poll() call we can then
have only one thread and one connection. The thread always blocks for
incoming messages. When Y wants to initiate an outgoing message Y can
just interrupt the blocking and send, and then the thread goes back
blocking on incoming messages. The idea is very similar to the "todo"
in the comment of socket_do_iteration():

/**
 * @todo We need to have a way to wake up the select sleep if
 * a new iteration request comes in with a flag (read/write) that
 * we're not currently serving. Otherwise a call that just reads
 * could block a write call forever (if there are no incoming
 * messages).
 */

So I guess at this time there is no off-the-shelf way to interrupt a
select sleep.

Comments?

Thanks,
Fan

On 7/28/07, Thiago Macieira <thiago at kde.org> wrote:
> Fan Wu wrote:
> >Please let me know if you have comments or better solutions.
>
> You didn't give us enough information on what your needs are to give you a
> proper solution. So I can only give you a generic one:
>
> Replace your blocking calls with asynchronous calls. That is, send the
> request over D-Bus and go back to your main loop event handler. That is,
> into your select()-based loop. Whenever there's data available in the
> D-Bus socket, you'll be notified and you can then (and only then) wake
> up, tell DBusConnection to process the data and continue your execution.
>
> No blocking, no threads.
>
> --
>  Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>   PGP/GPG: 0x6EF45358; fingerprint:
>   E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
>
>
>