Telling a Thread to Stop (Can it be done better ?)

[manasij7479]

I'm basically using std::future and std:: promise in a way just opposite to how it was intended to be used(i.e what it seems to me).
It works, but there should be a less kludgy way to do the same thing.

Before yelling "Premature Optimization" note that I'd like to use a similar construct to play around with sorting algorithms.
So, adding the extra check at every iteration may not be good....though the asymptotic complexity won't change (afaik).
(After that feel free to say so )

#include<iostream>
#include<future>
#include<thread>
#include<chrono>
void foo(std::promise<bool>& p)
{
    std::future<bool> f= p.get_future();
    long i=1;
    while(i++) //This is the loop I want to kill ...
        if(f.wait_for(std::chrono::seconds(0))==std::future_status::ready)
            break;
    std::cout<<"Counted to :"<<i<<std::endl;
    return ;
}
int main()
{
    std::promise<bool> p;
    std::thread t(foo,std::ref(p));
    while(true)
    {
        char c;
        std::cout<<"$:";
        std::cin>>c;
        if(c=='q')
        {
            p.set_value(true); //...by sending a message or setting a flag from elsewhere/
            break;
        }
    }
    t.join();
    return 0;
}

[phantomotap]

O_o

You aren't really using `std:romise' or `std::future' in an "opposite" way. You don't really seem to be using them in any way I'd call semantically correct (normal, opposite, backwards, or forwards). It isn't the "ordering" that makes me think you've done this poorly. It is that you aren't actually "returning" anything to a "calling" function which is what these functions imply.

I'd advise you to use a `std::conditional_variable' directly if you are only needing to "sequence" a particular kind of operation. Yes. That is all you are doing. If you don't see it, consider that you are only examining or setting a particular `bool' value. The variable referencing that `bool' value is owned by the shared `std:romise' object which just happens to be serializing (ordering) control to its member variables.

You can wrap that mechanism if you don't want to do it manually or you feel you may need such a mechanism often, but then I'd probably tell you that if you need this often you are probably doing it wrong.

If you have a "return a value" type situation you want `std:romise' and `std::future', but in general these situations will be packaged in such a particular fashion that the creation and management of these primitives are partially self-contained (which is why the standard provides such a facility).

Soma