- Boost - lists.boost.org

[serialization] New Primitive Types
by Andy Tompkins 16 Nov '07

16 Nov '07

Hi, If I create a new class, my_class, am I allowed to mark it as follows: BOOST_CLASS_IMPLEMENTATION ( my_class , boost::serialization::primitive_type ) The comments in level.hpp say that it won't call serialization code, thus I believe (and experience) that I don't need to provide either: template<class Archive> void my_class::serialize(Archive &ar, const unsigned int version) or template<class Archive> void serialize(Archive &ar, my_class &t, const unsigned int version) The comments also say that 'It presumes a member function or template in the archive class that can handle this type.' Does this mean that current archives (text, xml, and binary) are not able to use new primitive types without altering the archive to handle the new primitive? As I try it, both the text and xml archives use stream operators to convert my_class to a string and archive that. The binary archive casts my_class to a void* and outputs sizeof(my_class) bytes to the archive. It this expected behavior? Thanks, Andy.

1 0

[rfc] thread-safe monitor objects
by Frank Mori Hess 16 Nov '07

16 Nov '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've written a couple small classes to better support the creation of monitor objects, see: http://www.comedi.org/projects/libpoet/boostbook/doc/boostbook/html/poet/mo… I'd like to know if there's any interest in adding something like this to boost, and also looking for ideas on how to improve my implementation. It works via a monitor_ptr class, which is like a shared_ptr with automatic mutex locking, plus an (optional) monitor_base class that lets classes managed by monitor_ptr do wait/notifies on a condition. I put it in libpoet, but the monitor_ptr and monitor_base stuff really only depends on boost. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHPIjA5vihyNWuA4URAlXaAJ0YmyV2ZgBTOc1Okn29aHP3Of7R0gCfUrf3 6nVluGNuKFCEy59ukjQcbMY= =u0Sq -----END PGP SIGNATURE-----

2 2

[thread] TSS Cleanup on win64
by Anthony Williams 16 Nov '07

16 Nov '07

Please could someone with access to the MSVC compilers on a 64-bit platform replace libs/thread/src/win32/tss_pe.cpp with the attached version and run the test_tss_lib test from the thread library. Currently this test is failing on MSVC 8/win64 due to lack of automatic cleanup of TSS data. Hopefully the attached version of tss_pe.cpp will fix that. Thanks, Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

1 0

[thread] thread interruption semantics
by Preston A. Elder 16 Nov '07

16 Nov '07

Hey all, I just finally checked out the subversion version of boost (I was still on CVS, oops!). I noticed that the threading library now supports something called 'interruption', which seems to be at the thread level. While I applaud this effort (see a previous post where I created an interruptable_mutex) it has some major deficiencies. First, its presence in the boost::thread class gives the impression the thread can be interrupted at any time. This would mean behavior something akin to a pthread_kill() call in POSIX - which it does not. Second, the only thing it can interrupt in its current implementation is a condition - but unfortunately it does this by doing a broadcast to that condition which means two things. 1) ALL threads waiting on that condition wake up - which is not desired. 2) All threads waiting on that condition try to acquire the same mutex, meaning the thread you interrupted may have to wait for n other threads to acquire the mutex, check to see if they should have woken up, possibly do something, and then go back into the condition before the interrupted thread finally gets the lock, and the exception is thrown. And all this is assuming the coder wrote his code correctly to check to see if he got a condition notification correctly (ie. doesn't assume he can do something if he gets notified, and tries to do something erroneously). Third, interruption should also apply to locks - which would in part solve the above situation. The problem with this of course is that it is less efficient to use a mutex/condition crafted to work with interruptions at the lock level. If you want to continue to offer interruption (which, by the way, I fully support!) - I believe it should be done one of two ways. 1) Use a signal on POSIX systems and find some equivalent mechanism on other systems. This will then actually mean what the user thinks - thread::interrupt() interrupts the thread, not just breaks out of a condition if it happens to be in one. Or 2) Move interruption to its own series of structures. Like I did, with an interruptable_mutex. The advantage of this is twofold: 1) It can be implemented in a non-platform specific manner, using existing data structures, so you implement the interruptable version once (utilizing boost::mutex and boost::condition) and you don't have to care about the underlying platform. This means it doesn't require any OS specific support. 2) It works exactly as the user thinks. An interruptable_mutex can be interrupted while blocked on something to do with it (meaning when trying to acquire a lock on it, OR when waiting on a condition with it). Once again, I'll post the code to my interruptable_mutex - though of course it is based on the CVS (aka. boost 1.34.1) threading library: http://www.neuromancy.net/fisheye/browse/mantra/trunk/Mantra-I/mantra/utils… It uses an interruptable_pred as the predicate that signals the interrupt should happen. So you create an interruptable_pred that has a reference to an interruptable_mutex, and then lock the predicate or pass the predicate to a condition (I had to specialize the wait() functions in condition to make this work, but it DOES work). This allows you to have a single lock, but then have each thread have its own predicate, or even multiple threads to use the same predicate (so a single interrupt interrupts multiple threads potentially). Once again, I applaud you for including interruptions into boost::threads, but it really should be complete. I am probably going to try and re-write my interruptable_mutex to work with the new threading architecture (I will have to understand it better, and figure out how to replicate the current functionality), but in the mean time, something for you all to think about. PreZ :)

9 54

[thread] Shared Mutex views?
by Preston A. Elder 16 Nov '07

16 Nov '07

Is there any plan to implement something like this: http://www.neuromancy.net/fisheye/browse/mantra/trunk/Mantra-I/mantra/ utils/shared_mutex_views.h?r=435 So that a shared mutex can be operated like a normal mutex, including scoped_lock behavior, and you can choose whether that scoped_lock behavior should be to acquire an exclusive, a shared, or an upgrade lock? The idea being: // somewhere else shared_mutex smtx; // Where I need it: shared_mutex_view smv(smtx); shared_mutex_view::scoped_lock sl(smv); // ... // OR: exclusive_mutex_view smv(smtx); exclusive_mutex_view::scoped_lock sl(smv); Right now, shared_mutex only has primitives, and cannot be used with things like scoped_lock (aka. unique_lock). Additionally, it cannot be used as a condition, despite the condition framework. These views would facilitate that, however I'll admit, I've not thought of all the implications of such things. PreZ :)

2 2

[Thread] Wave segfaults at application cleanup in thread library
by Hartmut Kaiser 16 Nov '07

16 Nov '07

Hi all, Since a couple of days (2-3 days) the Wave tests started to fail because of a crash during application cleanup in the thread library (msvc-8, gcc3.4.5/Mingw - this problem seems to be constrained to the windows platform). The point of the segfault is here: boost/thread/win32/tss.hpp:+30, void cleanup(T* data) const { if(func) { func(data); // <-- here } else { delete data; } } Where data is a valid pointer, but func points somewhere. No code changes have been done lately in Wave (or in Spirit/Phoenix for that matter, because the tss is used in Spirit code). Any clues what might be the reason? Regards Hartmut

2 2

Formal review request: Unordered containers
by Daniel James 16 Nov '07

16 Nov '07

Hi, Please can you add the unordered container library to the review queue. It is an implementation of the unordered containers specified in TR1, with most of the changes from the recent draft standards (it's missing emplace which is tricky). It can be downloaded from: http://www.boost-consulting.com/vault/index.php?directory=Containers Either unordered.tar.gz or unordered.zip - they're both the same. Documentation is included in the download, and is also available on the web at: http://unordered.nfshost.com/doc/html/unordered.html The library has been tested with g++ 3.4, 4.1, 4.2 and Visual C++ 8. In the past it's been tested with some other compilers (intel on linux, borland, older versions of gcc and visual C++) and it'll probably still work on those (I haven't changed much since then). thanks, Daniel

5 6

[thread] use of __declspec(thread)
by David Deakins 16 Nov '07

16 Nov '07

I have been testing the rewritten code for the thread library on one of our applications. On this project we create a Windows DLL that internally uses Boost.Thread to spawn worker threads. I noticed that when some applications make use of the DLL, access violations are generated in set_current_thread_data() in win32/thread.cpp. current_thread_data was resolving to an address of 0. After some investigation the source of the problem turned out to be that __declspec(thread) cannot be used in a DLL if the DLL might be loaded using LoadLibrary. Per the Microsoft 'Rules and Limitations for TLS', If a DLL declares any nonlocal data or object as __declspec( thread ), it can cause a protection fault if dynamically loaded. After the DLL is loaded with LoadLibrary, it causes system failure whenever the code references the nonlocal __declspec( thread ) data. Because the global variable space for a thread is allocated at run time, the size of this space is based on a calculation of the requirements of the application plus the requirements of all the DLLs that are statically linked. When you use LoadLibrary, there is no way to extend this space to allow for the thread local variables declared with __declspec( thread ). Use the TLS APIs, such as TlsAlloc, in your DLL to allocate TLS if the DLL might be loaded with LoadLibrary. In our situation this is unfortunate, because the DLL is used with an optional component and we prefer not to require the DLL to be present when the optional component is not active. In light of this restriction, is it necessary to use __declspec(thread) for the current_thread_data variable or is the alternate boost::once implementation satisfactory? What improvements does the __declspec version offer over boost::once? Thanks, -Dave

2 1

[interprocess] Are there any pre-built docs about (+patch)?
by Darren Garvey 15 Nov '07

15 Nov '07

I can't currently build the interprocess docs (on windows, with MSVC9 beta2) because I'm getting an 'Access is denied' error. I have the latest xslt-proc binaries, which I thought solved this problem. It's failing at the doxygen stage so it might be a different problem altogether. There was also a missing space between two [endsect] tags, which caused it to fail when converting the quickbook source. I've put the simple patch in trac as ticket #1330. << BUILD_OUTPUT C:\cc\src\boost\trunk\libs\interprocess\doc>bjam <snip> ...patience... ...found 1114 targets... ...updating 7 targets... quickbook.quickbook-to-boostbook ..\..\..\bin.v2\libs\interprocess\doc\msvc- 9.0\debug\threading-multi\interprocess.xml Generating Output File: ..\..\..\bin.v2\libs\interprocess\doc\msvc- 9.0\debug\threading-multi\interprocess.xml doxygen-action ..\..\..\bin.v2\libs\interprocess\doc\msvc- 9.0\debug\threading-multi\autodoc-xml.xml-dir The system cannot find the file specified. Access is denied. del /f /q "..\..\..\bin.v2\libs\interprocess\doc\msvc- 9.0\debug\threading-multi\autodoc-xml\*.xml" & "L:/usr/bin/X11/doxygen" ..\..\..\bin.v2\libs\interprocess\doc\msvc- 9.0\debug\threading-multi\autodoc-xml.doxyfile && echo "Stamped" > "..\..\..\bin.v2\libs\interprocess\doc\msvc- 9.0\debug\threading-multi\autodoc-xml.xml-dir" ...failed doxygen-action ..\..\..\bin.v2\libs\interprocess\doc\msvc- 9.0\debug\threading-multi\autodoc-xml.xml-dir... ...skipped <p..\..\..\bin.v2\libs\interprocess\doc\msvc- 9.0\debug\threading-multi>autodoc-xml.doxygen for lack of <p..\..\..\bin.v2\libs\interprocess\doc\msvc-9.0\debug\threading-multi> autodoc-xml.xml-dir... ...skipped <p..\..\..\bin.v2\libs\interprocess\doc\msvc- 9.0\debug\threading-multi>autodoc-xml.boostbook for lack of <p..\..\..\bin.v2\libs\interprocess\doc\msvc-9.0\debug\threading-multi> autodoc-xml.doxygen... ...skipped <p.>autodoc.xml for lack of <p..\..\..\bin.v2\libs\interprocess\doc\msvc-9.0\debug\threading-multi> autodoc-xml.boostbook... ...skipped <p..\..\..\bin.v2\libs\interprocess\doc\msvc- 9.0\debug\threading-multi>interprocess.docbook for lack of <p.>autodoc.xml.. . ...skipped <phtml>standalone_HTML.manifest for lack of <p..\..\..\bin.v2\libs\interprocess\doc\msvc-9.0\debug\threading-multi> interprocess.docbook... ...failed updating 1 target... ...skipped 5 targets... ...updated 1 target... << BUILD_OUTPUT So, in the meantime, are there any docs online? The old link I found http://ice.prohosting.com/newfunk/boost/libs/interprocess/doc/html/index.ht… doesn't work anymore. Cheers, Darren

3 4

[1.35.0][tools] Tools build failure
by Beman Dawes 15 Nov '07

15 Nov '07

I'm starting to merge trunk changes into branches/release in my working copy. I won't do any commits until at least minimal tests are passing locally. The first merge was the tools directory, Boost.System, and Boost.Filesystem. Current versions of two libraries are needed by some of the tools. While we don't have an explicit test script for tools, I would expect the following to work correctly on Windows, given the working copy is d:\boost\release: d: cd \boost\release\tools\jam/src build copy bin.ntx86\bjam.exe a-directory-in-PATH cd \boost\release\tools bjam >log The bjam build works fine, but the tools build fails. See log file below. Shouldn't this work? Any ideas what's wrong? Note that the following does work OK, and builds process_jam_log.exe: cd \boost\release\tools\regression\build bjam Thanks, --Beman Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (don't panic: this is a strictly optional feature). D:/boost/release/tools/build/v2/build\virtual-target.jam:996: in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: <pregression\build\bin\msvc-8.0\release\link-static\threading-multi>tiny_xml.obj error: previous virtual target { msvc%msvc.compile.c++-tiny_xml.obj.OBJ { detail/tiny_xml.cpp.CPP } } error: created from regression/build/compiler_status error: another virtual target { msvc%msvc.compile.c++-tiny_xml.obj.OBJ { detail/tiny_xml.cpp.CPP } } error: created from regression/build/process_jam_log error: added properties: <define>_CRT_SECURE_NO_WARNINGS error: removed properties: none D:/boost/release/tools/build/v2/build\virtual-target.jam:459: in actualize-no-scanner from module object(file-target)@791 D:/boost/release/tools/build/v2/build\virtual-target.jam:111: in object(file-target)(a)791.actualize from module object(file-target)@791 D:/boost/release/tools/build/v2/build\virtual-target.jam:743: in actualize-source-type from module object(action)@796 D:/boost/release/tools/build/v2/build\virtual-target.jam:764: in actualize-sources from module object(action)@796 D:/boost/release/tools/build/v2/build\virtual-target.jam:709: in object(action)(a)796.actualize from module object(action)@796 D:/boost/release/tools/build/v2/build\virtual-target.jam:274: in actualize-action from module object(file-target)@797 D:/boost/release/tools/build/v2/build\virtual-target.jam:467: in actualize-no-scanner from module object(file-target)@797 D:/boost/release/tools/build/v2/build\virtual-target.jam:111: in object(file-target)(a)797.actualize from module object(file-target)@797 D:/boost/release/tools/build/v2/build\virtual-target.jam:832: in actualize-source-type from module object(non-scanning-action)@1180 D:/boost/release/tools/build/v2/build\virtual-target.jam:764: in actualize-sources from module object(non-scanning-action)@1180 D:/boost/release/tools/build/v2/build\virtual-target.jam:709: in object(non-scanning-action)(a)1180.actualize from module object(non-scanning-action)@1180 D:/boost/release/tools/build/v2/build\virtual-target.jam:274: in actualize-action from module object(file-target)@1181 D:/boost/release/tools/build/v2/build\virtual-target.jam:467: in actualize-no-scanner from module object(file-target)@1181 D:/boost/release/tools/build/v2/build\virtual-target.jam:111: in object(file-target)(a)1181.actualize from module object(file-target)@1181 D:/boost/release/tools/build/v2\build-system.jam:488: in load from module build-system D:\boost\release\tools\build\v2/kernel\modules.jam:261: in import from module modules D:\boost\release\tools\build\v2/kernel/bootstrap.jam:132: in boost-build from module D:\boost\release\boost-build.jam:9: in module scope from module

2 7