I think I understand Ken's point. One option on the doodle.com survey says, "I want multi-threading always on". This would require boost as a prerequisite (another option).
If these options is chosen, then compiling without multi-threading may not be an option. Therefore, if compiling with multi-threading which includes locking, is the only option, then is there a need to debug a single-threaded moses without locking? For my use case, it's only important for debugging to have stderr/stdout in proper order. I accomplish this now with multi-threading enabled and the --threads 1 option. This may not be the true for other use cases that require single threading with locking disabled when moses is complied for multi-threading. On Thu, 22 Sep 2011 11:33:10 +0100, Miles Osborne <[email protected]> wrote: > this is the last thing i will post here on this subject: > > debugging with a single thread running invokes the threading code. > ***if you suspect that this is somehow broken, then you need to debug > without it***. it is that simple. > > running gdb in single thread mode still uses threading. > > Miles > > On 22 September 2011 11:28, Kenneth Heafield <[email protected]> > wrote: >> But I don't see a use case for it. I can run gdb just fine on a >> multithreaded program that happens to be running one thread. And >> the >> stderr output will be in order. >> >> On 09/22/11 11:21, Miles Osborne wrote: >>> should someone want to debug with no threading, then there would >>> need >>> to be a mess of ifdefs removing all support for threading. i >>> agree, >>> this will be a pain to deal with, but this is what debugging with >>> no >>> threads means. >> >> _______________________________________________ Moses-support mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/moses-support
