Geoloquent, my rust + tokio + zbus port of Geoclue is now at a stage where it can be tested with existing geoclue clients. Most of these clients are based on libgeoclue which makes some unfortunate assumptions about how the D-bus server functions (single threaded, method calls started and finished sequentially on the order received etc.).
With a zbus-based server clients fail to start because properties need to be set on a client before its start() method is called, and the client library does not wait for the setters methods to finish before proceeding. I have a simple client side fix here, but it would be really nice to optionally fix this in the server as well, since I can't fix all the clients not using libgeoclue.
zbus has the spawn=false interface macro option which would seem to do exactly what I want, but testing shows that even with a single threaded executor (the rt option in tokio) the method dispatch order remains more or less random, and usually is LIFO rather than FIFO, with respect to the method sending order. The code in question is in this tree: https://gitlab.freedesktop.org/tpikonen/geoloquent/-/tree/spawn
From reading the thread from the PR (#675) where this feature was added, it looks like this problem is exactly what the spawn option was supposed to fix. Am I holding zbus somehow wrong, or is there a bug?
Geoloquent, my rust + tokio + zbus port of Geoclue is now at a stage where it can be tested with existing geoclue clients. Most of these clients are based on libgeoclue which makes some unfortunate assumptions about how the D-bus server functions (single threaded, method calls started and finished sequentially on the order received etc.).
With a zbus-based server clients fail to start because properties need to be set on a client before its
start()method is called, and the client library does not wait for the setters methods to finish before proceeding. I have a simple client side fix here, but it would be really nice to optionally fix this in the server as well, since I can't fix all the clients not using libgeoclue.zbus has the
spawn=falseinterface macro option which would seem to do exactly what I want, but testing shows that even with a single threaded executor (thertoption in tokio) the method dispatch order remains more or less random, and usually is LIFO rather than FIFO, with respect to the method sending order. The code in question is in this tree: https://gitlab.freedesktop.org/tpikonen/geoloquent/-/tree/spawnFrom reading the thread from the PR (#675) where this feature was added, it looks like this problem is exactly what the
spawnoption was supposed to fix. Am I holding zbus somehow wrong, or is there a bug?