Tracking DBusWatches

[tsuraan]

> This should work, but you have to be prepared for the dispatch to happen
> in this special dbus thread, and not in your main app thread. i.e. your
> filter functions and so forth will be called from whatever thread is
> doing the dispatch() on the connection.
>
> If you want to dispatch() in the main thread you can just read_write()
> in the separate thread, then get_dispatch_status() and if needed tell
> your main thread to do the dispatch.
>
> libdbus is fairly thread-safe but does have some quirks that need
> fixing, for example you can have issues if you
> dbus_connection_send()/dbus_connection_flush() in the main thread and do
> a blocking read_write() in another thread. (See a recent discussion on
> this list.) This is a bug in libdbus but perhaps hard to fix.
>
> If you use dbus *exclusively* in the separate thread you should
> encounter no problems that I can think of. Also if you do all
> read_write() and send()/flush() in the separate thread and dispatch() in
> the main thread I would not expect any problems.


Ok, so what I'm doing (and it is working, so far) is dedicating a thread to
read_write_dispatch.  It always calls that, with a -1 timeout.  In my main
thread, I am doing send_with_response, and it is also working.  The response
callback registered with pending_call_set_notify is obviously run in the
dispatcher's thread, but I handle that without any trouble.  I don't really
have much experience with multi-threaded programs or low-level sockets, but
all this discussion of read_write_dispatch blocking the socket would make me
think that what I'm doing shouldn't work.  What is the problem with blocking
sockets, and am I on the edge of hitting it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/dbus/attachments/20070209/28460f90/attachment.html