Re: [Felix-impl] flx::pthread::waitable_bool is one shot

[Rhythmic F. <rfi...@gm...>]

I added a reset_and_wait_until_true method.

Any dire predictions?

RF

On 28 September 2011 12:28, Rhythmic Fistman <rfi...@gm...> wrote:
> I just tracked down a CPU burning bug to felix's waitable_bool class:
>
> // a waitable boolean.
> class PTHREAD_EXTERN waitable_bool {
>  flx::pthread::flx_mutex_t cv_lock;       // to work with the condition var
>  flx::pthread::flx_condv_t finished_cond;
>  bool finished;   // might seem redundant, but that's how CVs work.
> public:
>  waitable_bool();
>
>  void wait_until_true();
>  void signal_true();
> };
>
> Felix uses it to politely ask threads to quit, which works fine.
>
> What I'd forgotten (or never knew) is that this is a one shot object -
> once set to true, it's always true and all further calls to
> wait_until_true correctly return immediately, hence my CPU burn.
>
> I'd like to modify it by adding a set_to_false method (not signal,
> because there's no wait_until_false!).
> I'm writing to this list to see if that raises any alarm bells (what
> if there are multiple waiters? in felix there aren't, nor are there in
> my use) and it would be nice to check such a change in, even though my
> branch of the demux/pthread stuff is fossilised at svn commit #1695
> because after that the lightweight pthread wrapper pulled in a bunch
> of garbage collection stuff.
>
> RF
>