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

From: Michel André (michel.andre_at_[hidden])
Date: 2003-01-25 10:46:04

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

Sure thing!

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

It would seem natural to be able to get it from the thread class but ill
guess in that case you would need to get a pointer to the "current" thread
instance and that might be hard if its from within a native thread. I guess
this isn't a problem if its separate from the thread class. Maybe the
current approach that allows both styles is good enough to gather
experience?

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

Is it in the dev branch or in the sandbox or is it still a thing between you
and Dave ;)?

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

Ok! Actually the only reason for me to want the old style is that it will
take longer for me to adopt 1.30 and later because I would have to convince
my CM guys to remake install and packaging, but thats more of a political
hurdle than a technical one. So it's ok. The only nitpick is that maybe a
version number in the dll name would seem good (not the lib name). Since
there might arise situations where a product consist of application A by
team A using boost 1.30 and another group B responsible for application B
using 1.xy which isn't compatible and they should share the same directory
which could cause problems, and this would be the most compelling reason to
have a library version as well. I don't know what others have to say about
this issue but I'll guess I will take the discussion internally since i
certainly would like to use the latest release ;).

/Michel