On Wed, Feb 8, 2012 at 10:08 AM, Chris Kühl <[email protected]> wrote:
> On Tue, Feb 7, 2012 at 8:19 PM, Patrick Ohly <[email protected]> wrote:
>> On Tue, 2012-02-07 at 12:44 +0100, Chris Kühl wrote:
>>> On Tue, Feb 7, 2012 at 9:23 AM, Patrick Ohly <[email protected]> wrote:
>>> > On Tue, 2012-02-07 at 09:04 +0100, Murray Cumming wrote:
>>> >> On Tue, 2012-02-07 at 03:35 +0100, Chris Kühl wrote:
>>> >> > Yeah, unfortunately things are not ideal. Have you given any further
>>> >> > thought as to how we are going to properly detect conflicting sync
>>> >> > sessions? This points getting close that this is going to need to be
>>> >> > dealt with. I've not looked into this at length yet. Is there no
>>> >> > interface I could use to test that syncs will not conflict?
>>> >>
>>> >> Nevertheless, it would be nice to punt this to a later patch/branch,
>>> >> just so we have some chance to get the current work into master.
>>> >
>>> > I agree. Let's keep the current behavior (only one session can run at a
>>> > time) and figure out how to detect non-conflicting sessions later. Don't
>>> > bite off more than you can swallow :-)
>>> >
>>>
>>> Ok, I'll reimplement the queue then.
>>>
>>> I was thinking that with an interface in place I could actually have
>>> the code in-place that would do the concurrent sessions even if now it
>>> would always return that there is a conflict. For testing that
>>> concurrent sessions do actually work with known, non-conflicting
>>> sources, we could introduce an environment variable that would return
>>> that there is no conflict. That way, as soon a solution is found ofr
>>> finding conflicts, is should just work.
>>
>> That makes sense.
>>
>
> Ok, should have this set up today.
>

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.

Cheers,
Chris
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution

Reply via email to