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

[john s. <sk...@us...>]

On 28/09/2011, at 8:28 PM, Rhythmic Fistman 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.



Well feel free to check any change in.

But more importantly I think: we need to reorganise Felix so you can use
the most recent version.

What's the problem with the GC code being pulled in?

A stub GC could be made (that throws an exception if any serious attempt
is made to use the gc). More "seriously" we could look at making the GC optional.

More "seriously" than that, we could look at a long term goal: to generate pure
C/C++ code (requiring no flx_run). Many Felix programs don't actually use
any p or f threading and so don't actually need flx_run.

Decoupling stuff isn't easy. Code in flx_run will call the collector entry points
in various places because if the collector IS being used it's necessary.

WRT my other mail on work schedule: I have big plans for making Felix more
dynamic (this was always intended!). Recently a way to incorporate custom
data structures into the gc was added, primarily this was to support Judy arrays.
However it could also be used to support C++ Vectors containing Felix pointers.
In fact the hard bit is distinguising between such vectors requiring scanning by
the gc and those that don't (eg vectors of ints).

I mention this because this is the first step towards a more dynamic type system.
The gc previously used an array of offsets to find pointers in an object, now
it will take an arbitrary scanning function. The ability to create, copy, move, and delete
dynamically defined types can also be added eventually.

Oh, and backstepping a bit: custom event loops such as the kind RF is using
need to be supported too. In fact it would be nice to be able to embed the whole
Felix system as callback of a third party event loops (of course that makes
using threads for async I/O a little tricky .. :)



--
john skaller
sk...@us...