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