Re: [boost] Re: boost.threads: Thread pool

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-01-25 09:41:30

Michel André said:
>>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:

[ snip ]

> 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.

Maybe you should send me a prototype implementation then.

>>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.

Yes, though I'm still debating about whether or not the id will be
seperate from the boost::thread class itself.  The current CVS state has
both.

>>* 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?

Sort of.  Dave Moore has been working on this, but I've not evaluated his
work in any way, so can't comment on whether or not there will be design
changes.

> 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?

Yes.  It vastly simplifies the build process (now that we have a working
DLL implementation), and is the version most users have been asking for
any way.  I did expect to get some static about this, so let the debate
begin. ;)  Note, however, that it will be a little problematic to continue
with a build process that provides both a forms, and that the
threadmon.dll has been the source of a lot of confusion for users, so
there will have to be very compelling reasons to bring this build type
back.

William E. Kempf
wekempf_at_[hidden]