- Boost - lists.boost.org

out of date comment in boost/config/compiler/visualc.hpp
by Marcin Kalicinski 10 Sep '05

10 Sep '05

boost/config/compiler/visualc.hpp has out of date comment at the end: // last known and checked version is 1310: #if (_MSC_VER > 1400) should probably be: // last known and checked version is 1400: #if (_MSC_VER > 1400) cheers, Marcin

2 1

Re: [boost] temp file
by Matt Doyle 09 Sep '05

09 Sep '05

> I didn't know about that, because on win32 there is a problem with > deleting open files. Using the WIN32 call CreateFile specify FILE_ATTRIBUTE_TEMPORARY. from MSDN -> FILE_ATTRIBUTE_TEMPORARY - A file is being used for temporary storage. File systems avoid writing data back to mass storage if sufficient cache memory is available, because an application deletes a temporary file after a handle is closed. In that case, the system can entirely avoid writing the data. Otherwise, the data is written after the handle is closed. You still can't delete an open file but you can possibly avoid ever creating the file in the first place.. Matt > On unix systems (probably most or all of them) > you can delete file and when last handle is closed kernel > automatically > removes file - it's great solution. > > Anyway, same people on unix (in same cases) first open temp file, > then remove it and then use it - no one could do anything > with your file. > > Tom <<snip>> Scanned by Fortigate {X3BTB534}

4 5

read_write_mutex fundamentally broken in 1.33?
by John Maddock 09 Sep '05

09 Sep '05

I've been trying to solve the deadlock problem reported here: http://lists.boost.org/Archives/boost/2005/08/92307.php but I've simply run into more and more problems, and just about every operation I've tried will deadlock if you try hard enough. THIS IS NOT GOOD. Applying Roland Swartz's suggested fix everywhere that looked appropriate initially seemed to fix the issue, but once you move to more complex situations (both readers and writers) then the deadlocks simply come back again. At this point I've exhausted my understanding of the problem and the design of the lock. As an aside: it is *very* hard to implement something like this correctly: no amount of debugging will ever get you a reliable system, only a clearly understood design backed up by a solid theoretical understanding of the implementation method (formal methods anyone?). To be honest I have to question whether it's even a good idea for this to be in Boost (no slur intended towards the implementers of that class, it's the difficulty of the problem that's the issue). In case anyone wants to pursue this further I'm attaching my current test case, and the current patches I have to the implementation, however, please note that neither this test case, nor the current regression tests are anything like comprehensive, THEY WILL NOT CATCH ALL POSSIBLE PROBLEMS. Sorry about the capital letters folks, but I suspect we have a "Huston, we have a problem" moment here :-( Regards, John.

8 15

Re: [boost] temp file
by Matt Doyle 09 Sep '05

09 Sep '05

> Matt Doyle wrote: > >>I didn't know about that, because on win32 there is a problem with > >>deleting open files. > > > > > > Using the WIN32 call CreateFile specify FILE_ATTRIBUTE_TEMPORARY. > > > > from MSDN -> FILE_ATTRIBUTE_TEMPORARY - A file is being > used for temporary storage. File systems avoid writing data > back to mass storage if sufficient cache memory is available, > because an application deletes a temporary file after a > handle is closed. In that case, the system can entirely avoid > writing the data. Otherwise, the data is written after the > handle is closed. > > > > You still can't delete an open file but you can possibly > avoid ever creating the file in the first place.. > > But then you have to carefully craft the spec, as users may > expect to be able to > share the file (by name) among processes. There are clearly > different use > cases for temporary files, so it is important to capture the > most important ones. Ah, that's true. There is a different flag that could be used FILE_FLAG_DELETE_ON_CLOSE which won't delete it until "all" handles to the file are closed but I really can't vouch for it because I haven't used that one. I've no idea what kind of nasty undocumented luggage it brings along with it. Given the source, I like to try it before I believe it ;) Matt > > Regards, > Stefan > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > Scanned by Fortigate {X3BTB534}

1 0

Re: [boost] temp file
by Greer, Joe 09 Sep '05

09 Sep '05

While you are thinking about this stuff, keep in mind that some OSes such as win32 have the ability to open a file as temporary and will automatically delete it when the last handle is closed. It would be nice if that could be exploited by whatever interface is decided upon. joe

3 2

Boost regression notification (2005-09-09 [HEAD])
by Douglas Gregor 09 Sep '05

09 Sep '05

<html> <head> <meta http-equiv="refresh" content="1; url=issues-email.txt"> </head> <body> <p>Update in progress (copying new results), please wait...</p> </body> </html>

2 1

Boost regression notification (2005-09-09 [RC_1_33_0])
by Douglas Gregor 09 Sep '05

09 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-09T15:57:06Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. concept_check Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 143 failures in 9 libraries: concept_check (12) foreach (1) math (3) mpl (1) multi_index (1) numeric/ublas (1) serialization (110) thread (8) wave (6) |concept_check| stl_concept_covering: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 |foreach| rvalue_const: vc-7_1 |math| octonion_test: gcc-4_0-darwin quaternion_test: gcc-4_0-darwin special_functions_test: gcc-4_0-darwin |mpl| size_t: gcc-4_0-darwin |multi_index| test_serialization: intel-win32-9_0 |numeric/ublas| test2: intel-9.0-linux |serialization| test_cyclic_ptrs_text_warchive_dll: vc-6_5 test_cyclic_ptrs_xml_warchive_dll: vc-6_5 test_delete_pointer_text_warchive_dll: vc-6_5 test_delete_pointer_xml_warchive_dll: vc-6_5 test_demo: intel-win32-8_1 test_demo_dll: borland-5_6_4 test_demo_exception: intel-win32-8_1 test_demo_exception_dll: borland-5_6_4 test_demo_shared_ptr: intel-win32-8_1 test_demo_shared_ptr_dll: borland-5_6_4 test_demo_xml_dll: borland-5_6_4 test_demo_xml_load: intel-win32-8_1 test_demo_xml_load_dll: borland-5_6_4 test_demo_xml_save: intel-win32-8_1 test_demo_xml_save_dll: borland-5_6_4 test_derived_class_ptr_text_warchive_dll: vc-6_5 test_derived_class_ptr_xml_warchive_dll: vc-6_5 test_derived_text_warchive_dll: vc-6_5 test_derived_xml_warchive_dll: vc-6_5 test_exported_binary_archive: vc-6_5 test_exported_binary_archive_dll: vc-6_5 test_exported_text_archive: vc-6_5 test_exported_text_archive_dll: vc-6_5 test_exported_text_warchive: vc-6_5 test_exported_text_warchive_dll: vc-6_5 test_exported_xml_archive: vc-6_5 test_exported_xml_archive_dll: vc-6_5 test_exported_xml_warchive: vc-6_5 test_exported_xml_warchive_dll: vc-6_5 test_list_ptrs_text_warchive_dll: vc-6_5 test_list_ptrs_xml_warchive_dll: vc-6_5 test_map_xml_archive: vc-6_5 vc-7_0 test_map_xml_archive_dll: vc-6_5 vc-7_0 test_map_xml_warchive: vc-6_5 vc-7_0 test_map_xml_warchive_dll: vc-6_5 vc-7_0 test_no_rtti_binary_archive: vc-6_5 test_no_rtti_binary_archive_dll: vc-6_5 test_no_rtti_text_archive: vc-6_5 test_no_rtti_text_archive_dll: vc-6_5 test_no_rtti_text_warchive: vc-6_5 test_no_rtti_text_warchive_dll: vc-6_5 test_no_rtti_xml_archive: vc-6_5 test_no_rtti_xml_archive_dll: vc-6_5 test_no_rtti_xml_warchive: vc-6_5 test_no_rtti_xml_warchive_dll: vc-6_5 test_non_default_ctor2_text_warchive_dll: vc-6_5 test_non_default_ctor2_xml_warchive_dll: vc-6_5 test_non_default_ctor_text_warchive_dll: vc-6_5 test_non_default_ctor_xml_warchive_dll: vc-6_5 test_non_intrusive_text_warchive_dll: vc-6_5 test_non_intrusive_xml_warchive_dll: vc-6_5 test_null_ptr_text_warchive_dll: vc-6_5 test_null_ptr_xml_warchive_dll: vc-6_5 test_nvp_text_warchive_dll: vc-6_5 test_nvp_xml_warchive_dll: vc-6_5 test_recursion_text_warchive_dll: vc-6_5 test_recursion_xml_warchive_dll: vc-6_5 test_registered_text_warchive_dll: vc-6_5 test_registered_xml_warchive_dll: vc-6_5 test_shared_ptr_132_binary_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_binary_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_132_text_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_132_text_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_132_xml_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_132_xml_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_binary_archive: borland-5_6_4 vc-6_5 test_shared_ptr_binary_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive_dll: borland-5_6_4 intel-win32-8_1 vc-6_5 test_simple_class_ptr_text_warchive_dll: vc-6_5 test_simple_class_ptr_xml_warchive_dll: vc-6_5 test_tracking_text_warchive_dll: vc-6_5 test_tracking_xml_warchive_dll: vc-6_5 test_unregistered_text_warchive_dll: vc-6_5 test_unregistered_xml_warchive_dll: vc-6_5 |thread| test_barrier_lib: intel-9.0-linux test_condition_lib: intel-9.0-linux test_mutex_lib: intel-9.0-linux test_once_lib: intel-9.0-linux test_read_write_mutex_lib: intel-9.0-linux test_thread_lib: intel-9.0-linux test_tss_lib: intel-9.0-linux test_xtime_lib: intel-9.0-linux |wave| test_re2c_lexer: cw-9_4 intel-9.0-linux test_slex_lexer: cw-9_4 intel-9.0-linux testwave: cw-9_4 intel-9.0-linux

1 0

[concept_check] New failures on RC
by Markus Schöpflin 09 Sep '05

09 Sep '05

A new test called stl_concept_covering has appeared in the concept_check lib on the RC branch. It currently fails for all platforms. Maybe it should have gone to the trunk? Markus

1 0

[filesystem] determine free space
by Simon Richter 09 Sep '05

09 Sep '05

Hi, I just ran across the problem of having to determine how much space was available for a new file that would end up at a certain path. I'd be willing to contribute such a function (convenience.hpp looks like a good place) for Unix, but it would have to be complemented by other OS dependent functions for the other architectures. Anyone interested? Simon

2 1

Re: [boost] [thread] Win32 call_once
by Greer, Joe 08 Sep '05

08 Sep '05

I have continued to think about the call_once() mechanism because many uses I can think of for it could require that it be called a lot. Therefore, I think we want the "normal" path to be as quick as possible. To that end, I was trying to come up with a way to use critical sections instead of named semaphores for the guard. I think I have managed that now, but it also occurs to me that we can test the flag up front to see if it has been set and if it has, we don't need to get any sort of guard. In the case that it hasn't, we can then acquire a guard (of some sort), re-test the flag (in case we have two threads running in parallel), and then execute the function. It looks a little uglier because of the double test, but it would execute faster because most of the time it would never have to get the guard. Hopefully there is something useful here. :) joe

2 1