Hmm? You keep everything as is (especially creating threads), but just put the “#pragma …” before the for-loop. So, there is one thread for the progress and one for the workers. In the workers thread OpenMP (if there) takes care of adding additional threads for parallelising the loop?
Or, am I wrong with that? > On 1. Mar 2018, at 16:11, Jeff Young <j...@rokeby.ie> wrote: > > But then the progress reporter won’t work (and you’ve got no way to cancel). > > Non-pooling parallel threads are sufficient for zone filling, aren’t they? > > >> On 1 Mar 2018, at 15:00, Bernhard Stegmaier <stegma...@sw-systems.de> wrote: >> >> For now it would probably be fine to just restore the pragma for the for >> loop optimisation. >> Mac users are used to work single-threaded, all others would get back >> multithreading here. >> >>> On 1. Mar 2018, at 15:58, Tomasz Wlostowski <tomasz.wlostow...@cern.ch> >>> wrote: >>> >>> On 01/03/18 15:43, Jeff Young wrote: >>>> The purpose is it works on Mac. >>>> >>>> But it does appear I misread the std::max( omp_get_num_procs(), 2 ) part. >>>> >>> >>> Thanks Jeff! >>> >>> Be aware that neither std::thread nor std::async have any concept of >>> thread pooling - we need to look for a suitable library or write or own. >>> >>> Cheers, >>> Tom >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : kicad-developers@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >> > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
