Re: When is a watch added/removed?

On 2019-07-22 13:54, Simon McVittie wrote:
> On Sat, 20 Jul 2019 at 10:14:48 +0200, David Henningsson wrote:
>> *dbus_connection_set_watch_functions* takes functions to add, remove and
>> toggle watches. I understand toggling watches can happen if read/write
>> buffers become full or empty, but are "add" and "remove" callbacks ever
>> called from anything else than dbus_connection_set_watch_functions itself?
> There is no API guarantee that libdbus will not add and remove watches
> under other circumstances. If you rely on watches only being added and
> removed from dbus_connection_set_watch_functions(), and your binding
> breaks with a future libdbus release, then I don't think we would consider
> that to be a bug in the future libdbus release.
>
> (Implementation detail: all current transports use a single socket. There
> is no API guarantee that there will not be a transport invented in future
> that uses multiple sockets, or doesn't use sockets at all.)
Okay, thanks for the clarification. This means that there is no way I 
can make a realistic test case, where I can check that I handle the 
add/remove callbacks correctly.
>
>> According to the documentation, a watch should not be added to the main loop
>> at all if it is not enabled, but is this really true - would it not make
>> sense to keep monitoring that fd for errors/hup/etc even though the watch is
>> disabled (because of filled/empty buffers)?
> If libdbus isn't in a suitable state to read in-band data from the socket,
> it probably also isn't in a suitable state to read an error or a hangup
> condition from the socket (which result in it synthesizing a message
> representing end-of-stream). Those conditions should be delivered when
> libdbus is ready for them, at which point it re-enables the watch.

Thanks, that makes sense.

>
> You might find it more appealing to wrap systemd's sd-bus (Linux-specific,
> low-level, each connection can only be used by a single thread,
> has a simpler/lower-level main loop abstraction based on epoll) or GLib's
> GDBus (portable, high- and low-level APIs available, designed to be
> thread-safe, more elaborate/higher-level main loop abstraction, but has
> heavier dependencies than sd-bus or libdbus).

Mostly FYI - for Rust, there is a main loop library called Mio/Tokio 
which seems to be the closest thing to a standard right now (i e, it's 
what most people use). So that's what I'm trying to improve 
compatibility with. So I need a main loop agnostic library.

What could be on the distant future roadmap, would be to completely 
replace libdbus with a Rust-only implementation. This would make cross 
compilation much easier, among other things.

// David
_______________________________________________
dbus mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dbus