Hi Here's my thoughts:
- there should be single and multi-thread compile paths so single-thread users don't pay the lock penalty. Maybe a -threads 0 works, but then you have to check a config each time you want to lock - boost should be required, but care about which packages we use - cruise control will help catch these compile path errors, once it's up and running Cheers Barry Sent from my ZX81 ----- Reply message ----- From: "Miles Osborne" <[email protected]> Date: Thu, Sep 22, 2011 11:33 Subject: [Moses-support] Multi-threading / Boost lib / compile error for threaded Moses To: "Kenneth Heafield" <[email protected]> Cc: <[email protected]> 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. > > -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. _______________________________________________ Moses-support mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/moses-support
_______________________________________________ Moses-support mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/moses-support
