-
Carlos Garnacho authored
Move this out of the Resources object, which is basically a view of the internal Store object. All event accounting and signaling is now performed by the Store object, to which the Resources DBus object connects to in order to implement GraphUpdated and Writeback signals. Only one handler of these events is possible at the moment, would be nice to consider doing something marginally better on the Steroids interface at some point, at least wrt the amount of data sent through the bus. Instead of trying to schedule the timeout across threads (the TrackerData hooks run in the thread performing the updates, and we want signaling done from the main/dbus thread), the code now just sets up a timeout on the main thread that keeps running as long as there are pending updates. When the task for the last batched update returns, it will be safe for the timeout to do signaling one last time and turn itself down, all of this happening in the main thread.
1d59f036