loop_executor should block on it's work_queue instead of polling

[Oberon00]

loop_executor::loop is currently:

    void loop()
    {
      while (!closed())
      {
        schedule_one_or_yield();
      }
      while (try_executing_one())
      {
      }
    }

The first loop repeatedly calls schedule_one_or_yield() which is simply

    void schedule_one_or_yield()
    {
        if ( ! try_executing_one())
        {
          this_thread::yield();
        }
    }

The current implementation uses unnecessary CPU cycles (esp. if all other threads are idle) by busy waiting. As concurrent::sync_queue<work> work_queue already supports a blocking wait_pull_front , it would be better to use a (private?) wait_executing_one that behaves just like try_executing_one but calls work_queue.wait_pull_front instead of try_pull_front.

IMHO, the current implementation is an outright performance bug.

[viboes]

Le 27/02/2017 à 19:42, Christian N. a écrit :

|loop_executor::loop| is currently: void loop() { while (!closed()) { schedule_one_or_yield(); } while (try_executing_one()) { } } The first loop repeatedly calls |schedule_one_or_yield()| which is simply void schedule_one_or_yield() { if ( !try_executing_one()) { this_thread::yield(); } } The current implementation uses unnecessary CPU cycles (esp. if all other threads are idle) by busy waiting. As |concurrent::sync_queue<work> work_queue| already supports a blocking |wait_pull_front| , it would be better to use a (private?) |wait_executing_one| that behaves just like |try_executing_one| but calls |work_queue.wait_pull_front| instead of |try_pull_front|. IMHO, the current implementation is an outright performance bug.

Hi, you are surely right. Would you mind to add a github issue? What about adding a pull request PR? Vicente

[viboes]

Sorry. I didn't saw this was already a github issue.
What about adding a pull request PR?

[Oberon00]

Ok, will do (but not before tomorrow).