Re: [SyncEvolution] DBus server rework: sync, shutdown, and password request
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.