|
From: Rhythmic F. <rfi...@gm...> - 2011-09-28 10:29:02
|
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
|