On Thu, 2013-02-07 at 21:47 +0100, Lukas Zeller wrote: > On 07.02.2013, at 14:14, Patrick Ohly <[email protected]> wrote: > > > On Thu, 2013-02-07 at 13:46 +0100, Christof Schulze wrote: > >> I started with a one-way-sync from phone to syncevo-http-server. > >> This caused syncevolution to remove all data from owncloud, which is > >> perfectly fine. However doing so takes about one second for each entry > >> causing the phone to report a timeout after a while. > >> > >> What is your take on that? Shouldn't syncevo-http-server try to keep the > >> session to the phone open? > > > > The session is kept open; it's the phone decides that it is waiting too > > long for a reply and therefore aborts. I know that the Synthesis SyncML > > engine can send empty messages to inform the client that it is still > > alive, but I am not familiar with how that works in detail. > > > > Lukas, can you say more about this feature? When does it kick in? > > This only works during loading the sync set, and only if libsynthesis > is configured to allow threads (<multithread> set). Then, the initial > loading operation (performStartSync()) is run in a separate thread > while the main thread issues a (empty) response every > <requestmaxtime>.
I'm looking into enabling that for SyncEvolution. Some questions, if I may... With <subthreadmode>none</subthreadmode> for logging, is the shared logger instance really thread-safe, or should this mode rather be avoided? I don't see any mutex locking. My understanding is that logging will not look nice when different threads open and close blocks in the wrong order in the same .html file, which does indeed happen when 'ReadSyncSet' block continues while the main thread sends an intermediate reply. So that alone may be a reason to avoid the single-file approach, although multiple files will make debugging harder. Which defines do I need to change where to enable thread support? There is a comment in "define.h" which says that the __MAKE_THREADSAFE option was moved to "target_options.h", but I don't see that option there. __MAKE_THREADSAFE seems to be for the SyncML Toolkit. For the Synthesis engine, I am setting MULTI_THREAD_SUPPORT and MULTI_THREAD_DATASTORE in "target_options.h". Does that sound right? Patch attached. -- 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.
diff --git a/src/Targets/ReleasedProducts/combiEngine_opensource_linux/define.h b/src/Targets/ReleasedProducts/combiEngine_opensource_linux/define.h index 42b2247..85545a2 100644 --- a/src/Targets/ReleasedProducts/combiEngine_opensource_linux/define.h +++ b/src/Targets/ReleasedProducts/combiEngine_opensource_linux/define.h @@ -59,7 +59,8 @@ /* thread safety (added by [email protected], 2001-10-29) */ /* Note: moved define of this to target_options.h of every target */ -#undef __MAKE_THREADSAFE +#define __MAKE_THREADSAFE + /* enable Alloc helpers */ #define __USE_ALLOCFUNCS__ diff --git a/src/Targets/ReleasedProducts/combiEngine_opensource_linux/target_options.h b/src/Targets/ReleasedProducts/combiEngine_opensource_linux/target_options.h index c6f8b09..96f33d3 100644 --- a/src/Targets/ReleasedProducts/combiEngine_opensource_linux/target_options.h +++ b/src/Targets/ReleasedProducts/combiEngine_opensource_linux/target_options.h @@ -191,6 +191,9 @@ // - string localIDs with sufficiently large size #define STRING_LOCALID_MAXLEN 256 +// - multithreaded +#define MULTI_THREAD_SUPPORT 1 +#define MULTI_THREAD_DATASTORE 1 // - if defined, SQL support is included #undef ODBCAPI_SUPPORT
_______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
