How to use ExecOne in main thread without blocking?

[hanyukang]

Hi,

This may be a silly question, but I'm stuck in this for a while and need some help.

I put the scheduler in the main thread because my callbacks use quite a lot of variables which only the main thread is in charge of updating them. The main thread can't be blocked as other modules need to update as well. I try to use ExecOne() in the Scheduler_Run() but the terminal seems to block the keyboard input as I can't type anything on it.
This happened only in Linux build, the Windows build was working fine...

Not sure if I'm using this lib correctly, the code looks like this,

int main()
{
	while (true)
	{
		Module1_Run();
		Module2_Run();
		...
		Scheduler_Run();
	}
}

[daniele77]

First of all, thank you for using cli library.
If you like it, please add a star to the project and -- if you want -- consider donating to support our work (just click the heart button on top of the page).

As far as concern your problem: I need to know:

1. the functions ModuleN_Run() can block?
2. What's inside Scheduler_Run()?

[hanyukang]

Thanks for your reply.

As for your questions,

1. All the Module_Run wouldn't block the main thread, they are just updating some variables.

2. I tried to use cli::BoostAsioScheduler Run() in the Scheduler_Run(), the WorkGuard would block the main thread and can't execute Module_Run() in the while loop anymore. If I change to cli::BoostAsioScheduler ExecOne(), the terminal seems to block the keyboard input, which only happened on Linux, I can still type commands and got callbacks on Windows.

Here is the code I run the test, with using MainScheduler = cli::BoostAsioScheduler;

#include "cli/clilocalsession.h"
#include "cli/cli.h"

int main()
{
	auto rootMenu = make_unique<Menu>("cli");

	Cli cli(std::move(rootMenu));
	MainScheduler scheduler;
	CliLocalTerminalSession localSession(cli, scheduler, std::cout, 200);

	while (true)
	{
		scheduler.ExecOne();
	}
}

[hanyukang]

I might find the problem,

It's because the work_guard only exist in the scheduler.Run(), and the underlying boost::asio::run_one always return because there's no outstanding work, so the solution would be to put the work_guard as a member variable besides the io_context?

 void Run()
    {
        auto work = ASIOLIB::MakeWorkGuard(*context);
        context->run();
    }

std::size_t scheduler::run_one(boost::system::error_code& ec)
{
  ec = boost::system::error_code();
  if (outstanding_work_ == 0)
  {
    stop();
    return 0;
  }

  thread_info this_thread;
  this_thread.private_outstanding_work = 0;
  thread_call_stack::context ctx(this, this_thread);

  mutex::scoped_lock lock(mutex_);

  return do_run_one(lock, this_thread, ec);
}

I've tested this code, it's working fine on both Windows and Linux, I only added a work_guard before executing the scheduler.ExecOne();

#include "cli/clilocalsession.h"
#include "cli/cli.h"
#include "boost/asio.hpp"
 
 int main()
 {
 	auto rootMenu = make_unique<Menu>("cli");
 
 	Cli cli(std::move(rootMenu));
 	MainScheduler scheduler;

	auto work = boost::asio::make_work_guard(scheduler.AsioContext());
 	CliLocalTerminalSession localSession(cli, scheduler, std::cout, 200);
 
 	while (true)
 	{
 		scheduler.ExecOne();
 	}

	scheduler.Stop();
	work.reset();
 }

[hanyukang]

And for the LoopScheduler, removed the condition_variable and added a dirty flag to indicate whether there's pending tasks

class LoopScheduler : public Scheduler
{
public:
    LoopScheduler() = default;
    ~LoopScheduler() override
    {
        Stop();
    }

    // non copyable
    LoopScheduler(const LoopScheduler&) = delete;
    LoopScheduler& operator=(const LoopScheduler&) = delete;

    void Stop()
    {
	dirty = false;
    }

    void Run()
    {
        while( ExecOne() ) {};
    }

    void Post(const std::function<void()>& f) override
    {
        std::lock_guard<std::mutex> lck (mtx);
        tasks.push(f);
	dirty = true;
    }

    bool ExecOne()
    {
        if (!dirty)
	    return true;

        std::function<void()> task;
        {
	    std::lock_guard<std::mutex> lck(mtx);
            task = tasks.front();
            tasks.pop();
	    dirty = !tasks.empty();
        }

        if (task)
            task();

        return true;
    }

private:
    std::queue<std::function<void()>> tasks;
    std::mutex mtx;
    std::atomic<bool> dirty{ false };
};

[daniele77]

As I wrote in another post, I guess you need a new scheduler non-blocking function.
However, I'd prefer to add a new function rather than modify the existing ExecOne. E.g.;

class LoopScheduler
{
...
bool ExecOne()
{
    std::function<void()> task;
    {
        std::unique_lock<std::mutex> lck(mtx);
        cv.wait(lck, [this](){ return !running || !tasks.empty(); });
        if (!running)
            return false;
        task = tasks.front();
        tasks.pop();
    }

    if (task)
        task();

    return true;
}

bool PollOne()
{
    std::function<void()> task;
    {
        std::unique_lock<std::mutex> lck(mtx);
        if (!running || tasks.empty())
            return false;
        task = tasks.front();
        tasks.pop();
    }

    if (task)
        task();

    return true;
}
...
};

class AsioScheduler
{        
 ...
void ExecOne() { context->run_one(); }
void PollOne() { context->poll_one(); }
...
};

[hanyukang]

Yes, your way is better, Poll is the non-blocking call.

Much appreciated your help!

[daniele77]

I'm gonna open an issue and then we're adding the new function to the library.

[daniele77]

issue #127

[daniele77]

Yes, I guess you found the root cause of the problem.
I just have a couple of comments about your problem / solution:

1. if you use LoopScheduler instead of BoostAsioScheduler, it works fine without the need to add the work guard. So, if your application doesn't need remote sessions, you can consider using LoopScheduler removing in that way the dependency from (boost) asio library.
2. please note that ExecOne() blocks until a key has been pressed. This means that in your code ModuleN_Run(); are not executed until the user hits a key of the keyboard. I suspect this is not the behavior you're looking for. To have ModuleN_Run(); called periodically, the library should provide a non-blocking function NonBlockingExecOne() that returns immediately when the task queue is empty.

[daniele77]

@hanyukang
I've just committed the PollOne() method also for [boost] asio schedulers, for consistency.
As you can see, I embedded the work guard in the scheduler object, so that you don't need to create it in your application.
Let me know if it's right.

[hanyukang]

@daniele77
I have some ideas to embed the work guard in BoostAsioLib and StandaloneAsioLib, same as you did for the Executor class, also the GenericAsioScheduler::Stop() should be calling work_guard.reset() method as I remembered... I can have a look at it later this week or next week.

[daniele77]

It would be great if you can review my last commit.