>commit a0a7a659c606eb1c77062a0881c617ff8bcf9ac9 >Author: Patrick Ohly <[email protected]> >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.
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. -- Regards, Congwu _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
