On Thu, Feb 16, 2012 at 2:29 PM, Patrick Ohly <[email protected]> wrote: > 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.
I wouldn't take too close a look at it just yet, I'm still working on getting some fundamental pieces working, like the main loop dance in the helper. > 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? > Yes, in this instance the client is expecting the the Reply signal so we can definitely do without this blocking call. This is actually how I wish the entire DBus interface worked; make a request and wait for a signal that delivers the requested data. However, blocking calls are necessary in the cases where the client expects a return value when complete or an error message on failure. > 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. True, this a problem and would require breaking the DBus interface to work. The only way I know how to get around this is the make the public DBus interface asynchronous. > > 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. > I'll be happy to rework the public DBus interface to get this to work like this. This, of course, will require that all the clients learn this new interface and, maybe more painfully, the test suite will need to be extensively reworked. But it would definitely make the dbus-server cleaner and some things possible at all. Cheers, Chris _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
