[boost] Re: boost.threads: Thread pool

From: Michel André (michel.andre_at_[hidden])
Date: 2003-01-24 19:08:32

>Depends on the time frame of the next release and how fast I can finish my
>work on the library.  If it's not in 1.30.0, it will be in 1.31.0.  In the
>mean time, if it's important enough to you, you can track the work in
>progress in the "thread_dev" branch in CVS.

Thanks! Will check out.

>> Also some kind of alarm or timer would be
>> useful.
>
>Not something in the todo hopper.  Can you give a more concrete
>explanation of what you want, and why you think it's important for
>inclusion.

As a simple way to get a function called at regular interval, something i
often use for periodic polling of connection status eg for db connections or
other periodic tasks.

A simple interface like:

struct alarm
{
     alarm();

     // constructor setting alarm
     alarm(function0<void> callback, xtime alarmTime, unsigned int
intervalMsecs = 0);

    // will do a cancel to ensure callback isn't called after destruction of
alarm
    ~alarm();

     // set alarm to go off (if intervalMsecs is 0 its a one shot alarm)
     void set(function0<void> callback, xtime alarmTime, unsigned int
intervalMsecs = 0);

     // stop alarm synchrounously no active callbacks after this point
     // you must be abel to cancel alarm from all threads especially from
    // within the callback.
    void cancel();
}

The idea is that all alarms should share on timer thread and a thread pool
and a priority queue (or maybe these things should be in an alarm_queue
class which an alarm is associated with, but there should be a system
default if an
alarm_queue class isn't given). There are some thorny issues when
implementing the alarm and alarm_queue class which is easy to get wrong
therefore I think its general purpose enough and belongs in a thread
toolbox.

>Right now, most of the work is being done on boost::thread itself.  This
>includes a reference-counted implementation instead of a non-copyable
>implementation, the addition of attributes such as stack size/address and
>priority scheduling and the addition of cancellation.  I'm getting close
>to completion of the design/implementation and will be asking for a peer
>review soon.

Is it settled wether there will be some kind of portable id (preferably
streamable) i often put thread ids in log file entries.

>* Final integration of Dave Moore's classes, including thread_pool,
>rw_mutex and barrier.

Great!

>* Addition of shared memory constructs.

This is a needed one. Is there any preliminary sketches of what the
interface will be like?

Ok!

Another question i noted that in the current boost CVS the boost.thread only
builds a dll version of the library and no static ones, in earlier release
you only needed the dll when using tss? Is it supposed to be that way?

Regards
/michel