class WaitableObject
{
public:
  virtual void Wait(unsigned period) = 0;

protected:
  WaitableObject(){}
  virtual ~WaitableObject(){}

private:
  WaitableObject(const WaitableObject&);
  WaitableObject& operator =(const WaitableObject&);
};

typedef void* ThreadFuncArgType;
typedef void (*ThreadFuncType)(void*);

class Thread: public WaitableObject
{
public:
  virtual ~Thread();

  virtual Thread* Execute() = 0;
  virtual Thread* Execute(ThreadFuncType fn, ThreadFuncArgType arg) = 0;

  static Thread* CreateThread();
  static Thread* CreateThread(ThreadFuncType fn, ThreadFuncArgType arg);
  template <class T, void (T::*fn)()>
    static Thread* CreateThread(T* obj);

protected:
  Thread();

private:
  Thread(const Thread&);
  Thread& operator =(const Thread&);
};

//////////////////////////////////////////////////////////////////////////
// helpers

template <class T, void (T::*fn)()>
  void ThreadFuncImpl(void* arg)
{
  T* instance = reinterpret_cast<T*>(arg);
  (instance->*fn)();
}

#define CREATETHREAD(klass, method, object)\
Thread::CreateThread(ThreadFuncImpl<klass, klass::method>, object)

#define CREATETHREAD_EXECUTE(klass, object, method)\
CREATETHREAD(klass, method, object)->Execute()

#define CREATETHREAD_EXECUTE_WAIT(klass, object, method)\
CREATETHREAD_EXECUTE(klass, method, object)->Wait()

void fn()
{
  class A
  {
  public:
    void Do(){}
  };

  CREATETHREAD_EXECUTE_WAIT(A, Do, new A); 
}

void func1 (void *){...}
Thread thread1 (func1);
thread1.start();
...
thread.stop();

class Some {
private:
    void func2 (void *);    
    void func3 (void *);
    Thread thread2;
    Thread thread3;


public :
    Some : thread2(&func2, this), thread3 (&func3, this)
    {
        thread2.start();
        thread3.start();
    }
    ~Some
    {
        thread2.stop();
        thread3.stop();
    }
}

void my_print( void )
{
    printf( "hello\n" );
    Sleep( 5 * 1000 );
    printf( "world\n" );
}

struct some 
{
    void foo()
    {
        Sleep( 500 );
        printf( "from foo()\n" );
        Sleep( 3 * 1000 );
        printf( "end foo()\n" );
    }
};

struct thread_runner
{
    thread_runner( some * sm ) :
        th1( boost::bind( &some::foo, sm ) ),
        th2( &my_print )
    {
    }

    ~thread_runner()
    {
        th1.join();
        th2.join();
    }

    boost::thread th1;
    boost::thread th2;
};

int main( int argc, const char **argv )
{
    some s;
    {
        thread_runner runner( &s );
    }
    printf( "main\n" );
    
return 0;
}

class Some {
public :
    Some : thread2(&func2, this), thread3 (&func3, this) {...}
}

class CallImpl {
private :
    CallImpl (const CallImpl&);
    CallImpl& operator = (const CallImpl&);

public :
    CallImpl () {;}
    virtual ~CallImpl () = 0 {;}
    virtual unsigned call (void* arg) const = 0;

};

class Caller : public CallImpl {
private :
    boost::function <unsigned (void *)> m_func;

    Caller (const Caller&);
    Caller& operator = (const Caller&);

public :
    explicit Caller (unsigned (*func)(void *)) : m_func (func) {;}

    template <class T>
    Caller (T& obj, unsigned (T::*func)(void *))
        : m_func (boost::bind (func, &obj, _1)) {;}

    virtual ~Caller () {;}
    virtual unsigned call (void* arg) const
    {
        return m_func (arg);
    }

};

class Thread {
private :
    boost::shared_ptr <CallerImpl> m_caller;

public :
    Thread (const boost::shared_ptr<Caller>& caller)
    ~Thread();
}

K>>>мне кажется что объект-поток должен отвечать только за корректный запуск и остановку потока. А "чтоб при его убийстве у тя не было ликов (памяти, дескрипторов, и еще черт знает чего)" это не его проблеммы, а проблеммы разработчика самой потоковой функции. Ведь системной _beginthreadex это тоже по барабану

Z>>корректный с чьей точки зрения? -- системы наплевавшей на кучу объектов нуждающихся в нетривиальном удалении?

Z>>такой подход тоже имеет право на существование -- вот поэтому мне и не нравятся бустерные threadы (и многие другие библы по сути являющиеся wapperами (разной степени корявости) над системными Сишными функциями)

Z>>разумееца программер должен следить за кучей всего в своей проге (вместа того чтоб сконцентрироватся над задачей ) -- но это не наш way

int foo(int, const std::string&) { ... }
...
thread_wrapper thr(&foo);
thr.start(10, "sample string");

void my_threaded_function(...)
{
    ...
    MyMegaObjectWithDestructor obj(...);
    some_mutex.lock();
    ...
    some_mutex.unlock();
    ...
}

Z>передать то можно и эот даже хорошо! но есть одна маленькая проблемка: в функтор еще нужно передеать параметры -- подумай вот над чем:

Z>int foo(int, const std::string&) { ... }
Z>...
Z>thread_wrapper thr(&foo);
Z>thr.start(10, "sample string");
Z>

Z>как реализовать start?

class Caller : public ICaller {
private :
    boost::function <unsigned (void *)> m_func;

    Caller (const Caller&);
    Caller& operator = (const Caller&);

public :
    template <class T>
    Caller (T& obj, unsigned (T::*func)(void *))
        : m_func (boost::bind (func, &obj, _1)) {;}
    explicit Caller (unsigned (*func)(void *)) : m_func (func) {;}
    virtual ~Caller () {;}
    virtual unsigned call (void* arg) const
    {
        return m_func (arg);
    }

};

class Thread : virtual public BaseThread {
private:

        void* m_arg;
    boost::shared_ptr<ICaller> m_caller;

    Thread (const Thread&);
    Thread& operator = (const Thread&);

    virtual unsigned execute (void)
        {
            return m_caller->call (m_arg);
        }

public:
    template <class T>
    Thread (T& obj, unsigned (T::*func)(void *), void* arg)
        : m_caller (new Caller (obj, func)), m_arg (arg) {;}
    virtual ~Thread ();
};

Z>ну это зависит от реализации -- причем ТВОЕЙ

Z>void my_threaded_function(...)
Z>{
Z>    ...
Z>    MyMegaObjectWithDestructor obj(...);
Z>    some_mutex.lock();
Z>    ...
Z>    some_mutex.unlock();
Z>    ...
Z>}
Z>

template <class BaseLock>
class Locker {

private :
    const BaseLock& m_lock;

    Locker (const Locker&);
    Locker operator = (const Locker&);

public :
    explicit Locker (const BaseLock& lock) : m_lock (lock)
    {
        m_lock.lock();
    }
    ~Locker ()
    {
        m_lock.unlock();
    }

};

class Mutex : public BaseLock {
private :
    HANDLE m_hMutex;

    Mutex (const Mutex&);
    Mutex& operator = (const Mutex&);

public :
    virtual bool lock (void) const;
    virtual bool unlock (void) const;

};

void my_threaded_function(...)
{
    ...
    MyMegaObjectWithDestructor obj(...);
    Locker<Mutex> lock (m_mutex);
    ...
}

Z>>интересно ктойта тебе пообещал вызвать деструктор??

Z>>твой thread умрет (!!) еще в конструкторе твоего Locker'a! -- и как уже было сказано не получит управления в зад (чтобы вызвать какиебы то ни было деструкторы!

K>ну чесно говоря — это спорный вопрос. Если система захотела убить вообще весь процес — аминь (это уж Билл пусть заботиться о безопасности)

void worker_thread(...)
{
    MyObjectWithDestructor obj(...);
    ...
    // в этой функции чтото долго и упорно вычисляется (или просто ктото притормаживает)
    // таким образом возникает timeout и worker_scheduler решает ее замочить...
    very_long_time_calculations_here();
    ...
}

void worker_scheduler(...)
{
    while (ходим по списку запущеных обработчиков)
    {
        ...
        if (текущий обработчик задержатся с вычислениями)
            // убиваем голубчика! результат уже никому не нужен...
            worker_threads[i].join();
        ...
    }
}

>> У меня в доморошенном потоке в joine стоит некое разумное время завершения, после чего прога поток заверщает и ругается на мои кривые руки правда это токо в дебаг режиме ...

...
thr.cancel();          // say 'DIE' to thread...
thr.join();            // wait for thread death...
...

If a thread terminates without releasing its ownership of a mutex object, the mutex object is considered to be abandoned. A waiting thread can acquire ownership of an abandoned mutex object, but the wait function will return WAIT_ABANDONED to indicate that the mutex object is abandoned. An abandoned mutex object indicates that an error has occurred and that any shared resource being protected by the mutex object is in an undefined state.

Z>да разумееца надолго зависать не хорошо... но отчитываться тоже ни перед кем не надо

Z>нужно всего лишь быть готовым обработать исключение thread_cancel и самозавершиться в случае его поимки

• Какой нить длииииииинный цикл, чего делающий
  
  Решение.
  аналог пресловутого is_canceled(). Но я бы назвал его MyMegaThread::CheckCancelFlag(). И вставлять его можно в некритичном месте затяжного цикла, но достаточно часто вызываемом для быстрой реакции на команды свали .. тьху, то есть, cancel
  
  
  
• Ожидание какого нить события (ну там в очередь пришли данные или еще чего). В этом обычно учавствуют ф-ции Wait... для Винды или select тд для Уникс
  
  Решение.
  Замена этих ф-ций на свои MyMegaThread::WaitForSingleObject() и MyMegaThread::WaitForMultiplyObjects()
  Если кто до сих пор не разгадал приема, поясню.
  На самом деле они все вызывают WaitForMultipleObjects c неким скрытым ивентом, который есть членом этого самого threada.
  Детали неясны (это же ведь только проект), но с ними можно определится в конкретной ситуации.
  Эта ф-ция тоже может бросить thread_canceled_exception, если сработает этот самый ивент
  
  
  
• Блокирующий вызова в ядро (различного рода read, write и тд)
  
  Решение.
  Это самый сложный случай из всех. И наверно именно из-за него советовали писать драйвер и другие подобные страхи (или покупать). Конечно, преимущество драйвера неоспоримо, ведь тогда он берет на себя работу по отслеживанию текущих блокировок и их корректному завершению, но тогда мы становимся его заложниками. Для большой системы это еще приемлемо, но не маленьких это неприемлемо.
  Ну голь на выдумки емка, так что можно всего лишь обойтись локальным хранилищем хендлов. Разумеется, чтобы все это дело автоматизировать, придётся писать фремворк, в котором необходимо завести базовый класс HandleBase, в котором и будет проходить вся работа по помещению хендла в таблицу возможно зависших хендлов MegaThreada.
  Многие скажут, что это гемор и всё такое, но на самом деле — не такой уж и гемор.
  Ведь есть всего несколько видов блокирующих хендлов — File, Socket, Pipe. Но всё равно всё сходится к файлам, к ним родимым.
  А для них всегда есть CancelIo или CloseHandle или в HandleBase можно определить виртуальную Cancel(), которая будет зависет от конкретного файлового дескриптора.