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

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-01-26 06:51:05

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

You'll always get the id from the thread class.  What's in question is
whether or not the thread class itself is enough of an ID (once it's
copyable, assignable, less-than-comparable and streamable), or if there
needs to be a seperate type for the id returned from an id() method. 
Currently, the dev branch has all of this.

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

In the dev branch, but I can't tell you what state it's in.

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

This should be happening with the stage rule, though I haven't confirmed.

William E. Kempf
wekempf_at_[hidden]