On 17.04.2013, at 11:38, Patrick Ohly <[email protected]> wrote:
>>> [...] >>> 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... Of course :-) > 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. It is not thread safe by itself, but relies on file io to serialize the output (kind of). But as you say: > 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, Exactly. To make that work, quite elaborate block hierarchy aware inserting of subthread's output would be needed (like temporarily closing all left-open blocks of the subthread logger after inserting a subthread's output and re-opening them at the beginning of the next subthread output chunk). I never bothered to implement this (although the structure of the logging system would allow it) just because... > although multiple files will make debugging harder. ...the split logfiles were easy to work with. The task done in a subthread is precisely defined - loading the syncset for a datastore. Only if there's was something related to loading the sync set to debug, the thread logs had to be examined. In all other cases, the main log contained everything, including clickable links to the subthread logs :-) The main log also gets less monstrous in size... > 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. Yes. Related history is as follows: Initially, the SyncML toolkit as coded by IBM (...) had lots of globals. When the subject of a multi-threaded server came up first, I had no clue about the toolkit's internals and tried to insert mutexes to protect the globals as a first attempt. That's where that __MAKE_THREADSAFE comes from. This approach failed, and when I understood the code better I found that all of the globals were related to the totally unnecessary (in libsynthesis context) "work space manager", so the solution was to rip WSM out (#define NOWSM). This made the SML instance free of globals and thus safe to use in a multithreaded server (one thread per session). > For the Synthesis engine, I am setting MULTI_THREAD_SUPPORT and > MULTI_THREAD_DATASTORE in > "target_options.h". Does that sound right? Yes :-) However, I would not recommend to set __MAKE_THREADSAFE. Best case was that it would do nothing, but that route was abandoned 12 years ago and never tested again, so it might also make the SmlTk fall apart... Best Regards, Lukas Zeller _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
