On Mon, 2012-02-13 at 14:50 +0100, Chris Kühl wrote: > So , I've pushed so changes taking us in this direction. Here is the > basic run down of what these changes include. > > - We've now got a priority queue of weak pointers implemented with a > std::set container that is initialized with a Compare class for > inserting new Resources based on their priority. > - There is a method (canRunConcurrently()) in Resource which is > checked but currently always returns false, thus forcing only single > session to be run. > - Once the Resource is made active it's placed the list of active > resources, a list of shared pointers to Resources. > - Implemented some of the outstanding issues with Connection (missing > communication between server and helper processes) > - Allow server process to set helper session's active state. > - Krzesimir implemented the missing functionality in the gio-gdbus > wrapper and added code to do blocking calls with minimal extra code > required in consuming classes. > > Note that in the above I always refer to Resources instead of Session > or Connection. Previously the Connection would create a session and > place it in the working queue but not activate the public dbus > interface. Because the Connection and the Session it spawns needs to > be in the same process. Thus the Connection is also queued but has a > higher priority than the other resources. > > The above mentioned changes compile and are being tested now. I'll get > back to you with the results of that.
How is that going? I'm now looking more seriously at the code myself. One thing which caught my attention is how blocking D-Bus calls are used in syncevo-dbus-server. For example, ConnectionResource::process(): it passes the incoming data on to the helper process with a blocking call. Isn't that a big no-no? If the helper is busy, won't that D-Bus call completely block all processing of any other events in the server for considerable periods of time? Worse, if syncevo-dbus-server is blocked in a call to the helper and the helper needs something from syncevo-dbus-server (like a password), then we have a deadlock. Even if other events do get processed while in a blocking D-Bus call, the result still won't be very pretty: basically we end up with a convoluted mixture of recursive calls, instead of a clean "process events, do something non-blocking, return to event loop" style. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
