July 2011 - Boost - lists.preview.boost.org

[Thread] Assertion on mutex when using multiple threads and mutexes
by Tim van den Kerkhof 22 Jul '11

22 Jul '11

Hi all, As a part of a project I'm writing a logger function. This logger function sends an e-mail when the program wants to log something. Since it has happened that the SMTP server was non responsive, I've decided to do the sending of the mails in a separate thread. This thread reads messages from an std::deque which is filled by the logging function. The thread is setup as follows: while (!boost::this_thread::interruption_requested()) { EmailItem emailItem; { boost::unique_lock<boost::mutex> lock(mMutex); while (mEmailBuffer.empty()) mCond.wait(lock); bufferOverflow = mBufferOverflow; mBufferOverflow = false; nrOfItems = mEmailBuffer.size(); if (nrOfItems > 0) { emailItem = mEmailBuffer.front(); mEmailBuffer.pop_front(); } } if (nrOfItems > 0) { bool sent = false; while(!sent) { try { ..... Do something with the message ..... { boost::this_thread::disable_interruption di; boost::lock_guard<boost::mutex> lock(mLoggerMutex); mLogFile << emailItem.mMessage << std::endl; } sent = true; } catch (const std::exception &e) { // Unable to send mail, an exception occurred. Retry sending it after some time sent = false; boost::this_thread::sleep(boost::posix_time::seconds(LOG_WAITBEFORE_RETRY)); } } } } The function log() adds a new message to the deque (mEmailBuffer) as follows: { boost::lock_guard<boost::mutex> lock(mMutex); mEmailBuffer.push_back(e); mCond.notify_one(); } When the main program exits, the destructor of the logger object is called. This is where it goes wrong, the application crashes with an error: /usr/include/boost/thread/pthread/mutex.hpp:45: boost::mutex::~mutex(): Assertion `!pthread_mutex_destroy(&m)' failed. The destructor merely calls an interrupt on the thread and then joins it: mQueueThread.interrupt(); mQueueThread.join(); In the main program, I use multiple different classes which make use of boost threading and mutex as well, could this cause this behaviour? Not calling the destructor of the logger object results in no errors, as does using the logger object and not doing anything else. My guess is I am doing something very wrong, or there is a bug in the threading library when using multiple threads divided over several classes. Does anyone have a idea what the reason for this error might be? Regards, Tim van den Kerkhof

1 0

[date_time] gcc visibility support patch
by Jürgen Hunold 22 Jul '11

22 Jul '11

Hi, I've found some patches for https://svn.boost.org/trac/boost/ticket/2114 This one enables visibility support for Boost.DateTime For more information, please see http://gcc.gnu.org/wiki/Visibility Tested locally for too long. Okay to commit? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 2

[C++0x] Emulate C++0x char16_t, char32_t, std::u16string, and std::u32string
by Beman Dawes 22 Jul '11

22 Jul '11

I'm starting to fold in Boost.Filesystem support for the new C++0x character types. Support is emulated for compilers and standard libraries not currently supporting the 0x features. The emulation is working fine, with tests passing on Windows for GCC 4.5 and 4.6, and VC++ 8, 9, and 10. Haven't tested on non-Windows systems yet. This is the same emulation approach Microsoft ships in VC++ 10. It seems to me that all Boost libraries that want to emulate these 0X features should use the a unified approach. Otherwise we could get into a situation where libraries A and B worked fine in isolation, but had symbol or ODR clashes when used together. The header I'm using is attached. I propose to place this in <boost/string_0x.hpp> rather than, say, <boost/filesystem/detail/string_0x.hpp>, and providing a simple doc page. Does this make sense? --Beman

6 15

[program_options] gcc visibility support patch
by Jürgen Hunold 22 Jul '11

22 Jul '11

Hi Volodya, I've found some patches for https://svn.boost.org/trac/boost/ticket/2114 This one enables visibility support for program_options. Tested locally for too long. Okay to commit? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 1

[Review] Lockfree review starts today, July 18th
by Hartmut Kaiser 22 Jul '11

22 Jul '11

Hi all, The review of Tim Blechmann's Boost.Lockfree library starts today, July 18th 2011, and will end on July 28th. I really hope to see your vote and your participation in the discussions on the Boost mailing lists! ----------------------------------------------------- About the library: Boost.Lockfree provides implementations of lock-free data structures. Lock-free data structures can be accessed by multiple threads without the necessity of blocking synchronization primitives such as guards. Lock-free data structures can be used in real-time systems, where blocking algorithms may lead to high worst-case execution times, to avoid priority inversion, or to increase the scalability for multi-processor machines. The following data structures are provided: - boost::lockfree::fifo, a lock-free fifo queue - boost::lockfree::stack, a lock-free stack - boost::lockfree::atomic_int, an atomic integer class The library is accessible from here: http://tim.klingt.org/boost_lockfree.tag.gz. Boost.Lockfree depends on C++0x atomics. They are not well supported with current compilers yet. For this reason Boost.Lockfree depends on the *unreviewed* Boost.Atomic library, that emulates C++0x atomics for C++98. This review is about Boost.Lockfree and not about Boost.Atomic, although it is included in the tarball and the git repository. If Boost.Lockfree will be accepted, it won't be merged into trunk before Boost.Atomic is accepted. --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards Hartmut Review Manager

9 17

[fusion] html docs woes
by Eric Niebler 21 Jul '11

21 Jul '11

I'm merging [72977] to release (<https://svn.boost.org/trac/boost/changeset/72977>) and am given a headache by the fact that Fusion has its HTML docs checked in. The docs are automatically generated from the qbk files so committing them to svn is strictly unnecessary, AFAICT. Why is this a problem? - Any change to any qbk file results in a huge number of diffs to the HTML docs (due to changed ids), resulting in a huge commit, long upload times, long download times, long merge times. - It makes viewing a changeset all but impossible because the meaningful changes are lost in the noise of meaningless diffs to automatically generated files. - It leads to unnecessary merge conflicts when merging commits from trunk to release. I'm going to have to regenerate the docs on the release branch and upload them all ... for no benefit! Can Fusion be changed to build its html docs as a normal part of Boost's doc build procedure like other Boost libraries? Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com

8 27

[lexical-cast] Help with documentation required
by Antony Polukhin 21 Jul '11

21 Jul '11

I've added Qickbook documentation for lexical_cast to libs/conversion/doc/lexical_cast.qbk and a Jamfile.v2 file to build it. Meanwhile, there is an old HTML documentation for lexical_cast in libs/conversion/lexical_cast.htm and file libs/conversion/index.html references it. The question is: How shall I update the lexical_cast.htm/index.html, doc/html/ folder? Best regards, Antony Polukhin

3 8

Re: [boost] [C++0x] Emulate C++0x char16_t, char32_t, std::u16string, and std::u32string
by Artyom Beilis 21 Jul '11

21 Jul '11

--- On Thu, 7/21/11, Beman Dawes <bdawes(a)acm.org> wrote: > From: Beman Dawes <bdawes(a)acm.org> > > You can't create working > > > > std::basic_ostringstream<char16_t> stream; > > > > Because stream << 1245 would not work due to > lack of std::locale facets. > > > > You can't create requires facets as for example they > are specialized > > in many standard libraries. > > Emulation via simple uint16_t and uint32_t typedefs doesn't > work for > all use cases. So only use it when it does work. > And Boost.Filesystem.v3 is one of these specific use cases. Boost.Filesystem uses codecvt facet? You can't create them, at least with gcc/linux because existing codecvt facets are specialized for each type of character - and you have to derive from it. For example this code would not link with Linux/gcc-4.6 #include <locale> class real_facet : public std::codecvt<char16_t,char,std::mbstate_t> { }; class simulated_facet : public std::codecvt<unsigned short,char,std::mbstate_t> { }; int main() { std::locale l1(std::locale::classic(),new real_facet()); std::locale l2(std::locale::classic(),new simulated_facet()); } With errors like: undefined reference to `std::codecvt<char16_t, char, __mbstate_t>::do_in(__mbstate_t&, char const*, char const*, char const*&, char16_t*, char16_t*, char16_t*&) const' --- : undefined reference to `std::codecvt<unsigned short, char, __mbstate_t>::do_max_length() const' > > Even existing Microsoft's VC2010 does not work if you > compile application > > with /MD or /MDd > > I'll retest just to be sure, but I'm fairly sure that some > of my tests > have used those switches. > MSVC2010 does not provide specialization for std::locale::id for these new facets and they are undefined in the dll. If you want I'll provide a fault case for MSVC10 as well. And all these with compilers that **declare** support of charXX_t. So you may try to put an effort in implementing some emulation but at these points char16_t/char32_t are broken with modern compilers. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

1 0

[interprocess][1.47] Mismatched PP directives?
by John Maddock 20 Jul '11

20 Jul '11

While building the PDF docs for 1.47 I noticed a bunch of Doxygen warnings about mismatched PP directives in the Boost.Interprocess source - warning messages below - should I/we be concerned, or this just a Doxygenism? Thanks, John. M:/data/boost/branches/release/boost/interprocess/permissions.hpp:55: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/permissions.hpp:68: warning: Found an #else without a preceding #if. M:/data/boost/branches/release/boost/interprocess/permissions.hpp:70: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/permissions.hpp:96: warning: Found an #else without a preceding #if. M:/data/boost/branches/release/boost/interprocess/permissions.hpp:98: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/permissions.hpp:109: warning: Found an #else without a preceding #if. M:/data/boost/branches/release/boost/interprocess/permissions.hpp:111: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/permissions.hpp:131: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/containers/containers_fwd.hpp:40: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/smart_ptr/intrusive_ptr.hpp:294: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/smart_ptr/scoped_ptr.hpp:168: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/smart_ptr/shared_ptr.hpp:388: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/sync/interprocess_barrier.hpp:115: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/sync/interprocess_mutex.hpp:148: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/sync/interprocess_recursive_mutex.hpp:158: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/sync/interprocess_semaphore.hpp:119: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/sync/named_mutex.hpp:235: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/sync/named_semaphore.hpp:242: warning: More #endif's than #if's found.

2 1

RFC: type erasure
by Steven Watanabe 20 Jul '11

20 Jul '11

AMDG Over the last few months I've re-done my type erasure library from scratch, fixing a lot of the bad design decisions I made originally. Here's a basic sample of what you can do with it: simulate boost::any: type_erasure::any< mpl::vector<copy_constructible<>, typeid_<> > > x(10); simulate boost::function<void(int)>: type_erasure::any< mpl::vector<copy_constructible<>, typeid_<>, callable<void(int)> > > f(foo); The code is available from the Vault: http://tinyurl.com/3z9jcwp The library is nearly complete. I've included pre-built html documentation in the zip. Questions, comments, and criticism are welcome. In Christ, Steven Watanabe

7 22