On Wed, 2009-11-25 at 02:34 +0000, Chen, Congwu wrote:
>commit a0a7a659c606eb1c77062a0881c617ff8bcf9ac9
>Author: Patrick Ohly <patrick.ohly(a)intel.com>
>Date: Tue Nov 24 22:01:23 2009 +0100
>
> SyncContext: only use one engine instance, fixes slow sync issue
>
> This removes code which was added as part of the some of the SAN
> handling patches. The code added a second Synthesis engine while the
> first one was still running, using this statement:
>
> // reinitializes the engine, only at this time can we decide whether
> // this is a server session or client session.
> SwapEngine swapengine(*this);
>
> I recognize the comment. It must have been copied from an older
> SyncEvolution revision. However, SyncEvolution no longer uses two
> instances of the engine, so this code can and has to be removed again.
> Instead the first instance is reinitialized once the full config is
> known.
>
Well, this will break server alerted sync case. The problem is:
1) we init the engine (for logging purpose, with the assumption that
this is a client session)
2) after we found this is a server alerted sync session and the
underlying SynthesisEngine must be reinitialized to a server session.
Okay, I see.
The solution I think of is:
1) Don't init the engine until we reliably know this is a server
session or client session (lost some logging capabilities)
Or
2) Move these routines (those need to be done before we finally detect
this is a server or client session) to another function, so that
leaving this function will automatically destruct the underlying
SharedEngine and reinitialize the real engine afterwards.
I agree with solution 2 and merged this patch into master.
--
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.