Re: [Boost-users] [thread] "almost works" clarification

Subject: Re: [Boost-users] [thread] "almost works" clarification
From: Michael Powell (mwpowellhtx_at_[hidden])
Date: 2013-05-22 12:08:00

On Wed, May 22, 2013 at 5:21 AM, Bjorn Reese <breese_at_[hidden]> wrote:
> On 05/21/2013 11:58 PM, Michael Powell wrote:
>
>> I ran across this article, which although a bit dated, is a pretty
>> good sketch of what I would consider a fairly robust thread runner
>> abstraction, which if you read past the frustration, makes good sense,
>> at least in my opinion:
>> http://peter.bourgon.org/blog/2008/12/12/boost-thread-kindof-sucks.html.
>
>
> The worker in this blog has a synchronization error. If stop() is called
> before run() -- this could happen due to thread scheduling -- then it
> will not stop.
>
> If you can live without the notify_all() in stop(), then a better
> solution is to pass a cancellation callback as an argument to run(),
> and check this instead of checking m_running. Something like this:

Yessir, this is not a half-bad thought actually, encapsulate the
canceled, or more generically "state" of which one mode is the cancel
request, could be others, like timeout, etc.

HTH

>   class cancellation
>   {
>     // Use atomic<bool>
>     virtual bool is_cancelled() const = 0;
>   };
>
>   class worker
>   {
>      void run(cancellation& state)
>      {
>        while (!state.is_cancelled())
>        {
>
>        }
>      }
>   };
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users