Alisdair Meredith said: > In view of the pending comittee meeting, and knowing those involved will > be wanting to tie down any loose ends, I'm going to ask a thread-related > question which relates as much to language support (I think) as boost > thread, but this seems to be the active place for threads/ISO at the > moment (please correct me if wrong) > > I am going through our logging code again as we now have competing > requirements and more rigorous requests for thread support. Currently > our logging goes through a singleton implementation (provided by Andrei > and the Loki library, thanks Andrei) but I would like to move to what I > would describe as 'singleton-per-thread'. > > The neat thing about singletons (or at least this implementation) is > that they exist for the lifetime of the process, potentially created > before main and destructed only after main has exited. I would like a > similar facility on a per-thread basis (tied to each thread's stack) > This would allow me to log from multiple threads without having to lock > the logger object, and without interspersing each threads messages > throughout the same log. > > Is such an implementation possible with the current boost::thread, and > is such an implementation currently under consideration in the lagnuage > extension TR wrt thread support?
Yes, this is trivially implemented with boost::thread_specific_ptr<>. Well, it may require the use of boost::once() as well, which complicates things a little, but it's not that bad. As for language extensions, that's still being thought on. > It would seem 'obvious' to me that I would want to create each logger > object in the stack of each thread, rather than as part of the parent > thread object owned by the thread creating the child-thread. I also > believe this logger example could quite easily be generalised to a whole > group of designs that want per-thread 'singletons', but the logger makes > a fairly clean example. Creating the singleton on the "stack" will require a bit more effort (possibly with a function object adapter to create the instance?), but is still feasable. William E. Kempf [EMAIL PROTECTED] _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
