>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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
