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
>Maybe you should send me a prototype implementation then.
>> 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
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
>>>* 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
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
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 ;).
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk