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