The idea of the thread and thread_container classes (threads.hxx)
-----------------------------------------------------------------

I got a base thread class that contains the interface pthreads (or whatnot)... this class is designed as parent for any thread. A derived class is supposed to define the thread_work() method to define the body of thread work. The actual C function executed for the thread calls this method via a polymorphic call to thread::thread_work().

This implies that the thread shall only be alive while the derived object is intact. You need to kill off the thread first, then call the specific destructor. Neither thread startup nor ending is automatic, you are supposed to call thread::thread_create() and thread::thread_kill() during lifetime of the derived object.

There's no way around that, as I see it... but, let's enter the thread container class. This one is, again, designed as something to inherit from. It is an aspect that for keeping track of threads. Basically, you design a class that contains a number of thread-derived members and is itself derived from thread_container. It inherits thread_container::create_thread() and thread_container::kill_thread() to create and kill threads and store them in an internal list for being able to get a listing of threads, mainly.

Now, I would like to automate the threading fun more. On one hand, there is a good argument for _not_ putting the creation of threads into some automagic part of a constructor. This is a complex operation that could fail badly due to many reasons -- and things in constructors generally shouldn't go wrong; at least not in a way that doesn't fully construct the object. Recovery is tricky... at least it would mean I really have to wholly embrace exceptions, which I still dislike. For now, the usual issue for constructors is running out of memory, and there is no sane remedy for that situation anyway; at least not on present-day default Linux systems, which will rarely tell you about memory shortness before it's too late. Also, systems will start trashing the disk on swap partitions / page files before admitting that they're out of memory. You're doomed anyway.

Back to my quest of automatization. At least the killing of threads would be convenient to have in a generic destructor. Some protection about simply forgetting to explicitly kill them off. Is this possible in the generic thread_container? Think about the order of constructor / destructor calls.

constructor: parent-members, parent, child-members, child
destructor:  child, child-members, parent, parent-members

Now... if parent is thread_container and some of child-members are threads ... the thread objects are dead already when reaching the generic thread_container destructor. Nuthin' you can do. So, both the thread and container base classes should spit out a fatal error if they reckon active threads in their destructors... I really need to clear up beforehand, guided by some base class members, but at leas one such a call has to happen.
