Support for interrupting output in telnet session

[korayko]

Hi Daniele,
First of all, thanks for sharing your great work with the community.
What I wonder, is there any way of stopping the output of a provided command which takes a considerably long time to finish at the telnet client side, by providing a CTRL+C signal or something else?

If not, do you think it is easily doable?
Thanks in advance.

[daniele77]

Hi @korayko ,
first of all, thank you for using the library and providing feedback.
Let me understand better your question: are you looking for a way to stop an activity you previously started with a cli command? E.g., like you do with the CTRL-C in bash?

[korayko]

Hi @daniele77
Yeah, this is exactly what I tried to mean.

[daniele77]

Ok, so I assume you want to stop the whole activity, not only stop "its output".

In my opinion, the right way to do so is:

1. make the "start" command asynchronous (i.e., the start command just start the activity but exit immediately. You can achieve this by using a worker thread or asynchronous I/O API).
2. have a "stop" command that terminates the activity (e.g., it stop the worker thread)

I'd prefer not to use signals (i.e., CTRL-C) because it has a completely different meaning: stop the whole application (inside a local session) or stop the telnet client (inside a remote session).

[korayko]

How is it possible stop to one worker thread from another?
If you mean that the worker thread must repeatedly check some shared flag status, it works, but it does not sound like a good design idea I think

[daniele77]

It's not necessarily a polling. It depends on your application architecture. In any case, when you have a long running activity, it can be:

1. many cycles of CPU bound computation OR
2. It can be a blocking I/O.

In the case 1 you should check a flag at each iteration.
In the case 2 you should use asynchronous I/O instead (e.g., asio) so that you don't have really blocking operations.

Please note that you can't do any better with signals. You can let a signal terminate the whole application (don't think it's a better solution 😉 ) or you can intercept the signal and... transform it again in a flag! that your time consuming activity must eventually intercept in some way (guess how? You will need to check the flag in a cycle, be it in the main thread or a slave thread).

Tell me which kind of activity your application must be able to stop, maybe with a little more context we can sort out a better solution.

[korayko]

I have defined a command which calls my handler function. In that function I am iterating through a container and print some of the fields of my custom class, contained in that container. Moreover, in order for that printing progress being able to be easily trackable by human eyes, I put sleep function call after each and everry print line.

If the lenght of the container is small, then it is not so much problem. Printing the output progress anyways finishes in a second or so. But on the other hand, if the number of elements in my container is considerably high then it takes a lot more time my command to be finished. So in that case when I am done with what I am looking for within the output, I would like to stop printing any more information by pressing a keyboard button

[daniele77]

@korayko
ok, it's clear now.
So, your example is a long running activity with I/O.
I would solve your problem in one of the following ways:

Worker thread

class MyContainer
{
public:
    MyContainer()
    {
        for (int i = 0; i < 100; ++i)
            values.push_back(i);
    }
    void StartPrint(std::ostream& out)
    {
        servant = std::make_unique<std::thread>(
            [this, &out]()
            {
                stopPrint = false;
                for (auto i: values)
                {
                    out << i << endl;
                    if (stopPrint.load()) break;
                    std::this_thread::sleep_for(500ms);
                    if (stopPrint.load()) break;
                }
            }
        );
    }
    void StopPrint()
    {
        stopPrint = true;
        servant->join();
    }
private:
    std::vector<int> values;
    std::atomic<bool> stopPrint;
    std::unique_ptr<std::thread> servant;
};

...
rootMenu->Insert(
        "print",
        [&container](std::ostream& out){ container.StartPrint(out); },
        "Print container" );
rootMenu->Insert(
        "stop",
        [&container](std::ostream& out){ container.StopPrint(); },
        "Stop print of container" );
...

Asynchronous timers

class MyContainer
{
public:
    MyContainer(boost::asio::io_context& io) :
        timer(io, 500ms)
    {
        for (int i = 0; i < 100; ++i)
            values.push_back(i);
    }
    void StartPrint(std::ostream& out)
    {
        current = 0;
        // schedule next print
        timer.expires_after(500ms);
        timer.async_wait([this, &out](auto){ PrintNext(out); });
    }
    void StopPrint()
    {
        current = -1;
    }
private:
    void PrintNext(std::ostream& out)
    {
        timer.cancel();
        if (current >= 0 && current < values.size())
        {
            out << values[current] << endl;
            ++current;
            // schedule next print
            timer.expires_after(500ms);
            timer.async_wait([this, &out](auto){ PrintNext(out); });
        }
    }
    std::vector<int> values;
    int current = -1;
    boost::asio::steady_timer timer;
};

...
rootMenu->Insert(
        "print",
        [&container](std::ostream& out){ container.StartPrint(out); },
        "Print container" );
rootMenu->Insert(
        "stop",
        [&container](std::ostream& out){ container.StopPrint(); },
        "Stop print of container" );
...

You only have these two possibilities if you want to be able to stop the activity, regardless of the cli library you're using.
Please note that signals don't solve the problem of having a servant thread or asynchronous timers, because you should intercept the signal and call the StopPrint method (the signal can only save you some keystrokes, but you can't currently manage them from telnet sessions).

I'd prefer the second version (asynchronous timers), because the problem you're solving is intrinsically I/O bounded, and it's more efficient to use asynchronous I/O.

[korayko]

Thank you @daniele77 to much. I will give the second way you suggested a try.
Appreciated.