- Boost - lists.boost.org

Re: [boost] [1.33.1][serialization] buginlibs\serialization\src\basic_iarchive.cpp and proposed patch
by JOAQUIN LOPEZ MU?Z 02 Sep '05

02 Sep '05

Robert Ramey <ramey <at> rrsd.com> writes: > > Joaquín Mª López Muñoz wrote: > > The recent updates to Boost.Serialization code in RC_1_33_0 > > can provoke a crash at run-time, as shown for instance > > in http://tinyurl.com/dwu78 (there are other, compile-time problems > > that I'm not addressing in tihs post.) > > What are these compile-time problems? As I'm writting this the report engined seems to be stuck, so I cannot give you an URL: CW 9.5 for Linux, for instance, fails to build the lib complanining about an ambiguous overload with state_saver (if my memory serves me well.) > > > The problem is located in reset_object_address. The attached > > patch to libs\serialization\src\basic_iarchive.cpp fixes the > > problem in my local tests, but as I lack the knowledge to > > be sure, I'd rather not commit it myself and let it be confirmed > > to be OK. > > I've put the fix in my local system and will be testing it soon. I don't > see any harm in it but I'm not quite sure it should be necessary either. Look at it this way: before the updates to Boost.Serialization code 34h ago, multi_index->test_serialization worked fine, now it doesn't and I haven't changed anything in my code base, so... Of course, the possibility exists that I'm using your lib in a wrong way. Also be aware that I don't really know what the patch is supposed to be doing: I've just copypasted from the previous version of reset_object_address implementation and verified that the problem went away. > I > looked at the files in multi-index and didn't find any reference to > reset_object_address so I'm still a little puzzled. More information > please? > In multi_index_container::load() (boost/multi_index_container.hpp) The error shows as follows: when loading a previously saved pointer to a tracked object, the returned pointer is bogus. Funny thing is that the object pointed to is *not* the one on which reset_object_address() is used. If you need more details on the problem as I debugged it, please tell me so. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] [boost thread rework] New version uploaded to BoostVault
by Greer, Joe 02 Sep '05

02 Sep '05

> -----Original Message----- > Running the test program, the semaphore version gives a timing of 16s > compiled > with gcc-mingw-4.0.1, and 22s compiled with MSVC 7.1, on my machine. The > mutex > version gives timings of 23s (gcc) and 29s (MSVC), so the semaphore > version is > clearly faster. > Why use either? I wrote an implantation using critical sections and my timings are: Semaphores: 20 Mutex: 27 Critical section: 0 I must be missing something vital. joe

2 1

[Boost-bugs] [ boost-Support Requests-1280829 ] Multithreaded process pausing but not deadlocking or crashin
by SourceForge.net 02 Sep '05

02 Sep '05

Support Requests item #1280829, was opened at 2005-09-02 10:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1280829&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Multithreaded process pausing but not deadlocking or crashin Initial Comment: Hi, I am writing a largely multithreaded linux program (20-60 threads) on version Fedora Core 2. I am using glib c version 2.3.3-27. In addition, I am using the boost libraries (version 1.32.0) for my threading and locking. Specifically, I am using mutexes, recursive_mutexes, scoped locking, and conditions. My problem is that the process will suddenly cease activity for random lengths of time (1 sec to minutes). However, it never crashes or produces incorrect results. Also, I do not think that it is deadlocking because it always resumes its activity. I have done some profiling of the locks, and it shows very strange behavior. For instance, threads will block for long lengths of time (the length of the inactivity) while no thread is holding the corresponding mutex more than fractions of a second. When I explored this further, it appears that thread A is blocking on a mutex while thread B holds it. I am using boost::recursive_mutex::scoped_lock objects for the locking. The weird thing is that thread B pauses at the very end of the lock's scope (again for a the length of inactivity), as though the attempt to unlock the mutex is not waking thread A and descheduling thread B for a long time. I created a test program that spawns 30 threads that just do a bunch of locking of these boost scoped locks and yielding. This program, too, shows the same downtime activity (again without crashing or deadlocking), though less frequently (I suspect because the locking pattern is probably different than in my program). It also always resumes its activity eventually. I have attached the test program code. I'm not sure whether this is a problem with the boost libraries or a linux problem, or my own problem. I was wondering if anyone has experienced similar behavior and might be able to offer some insight or guidance. Thanks! Matt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1280829&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[1.33.1][serialization] bug in libs\serialization\src\basic_iarchive.cpp and proposed patch
by Joaquín Mª López Muñoz 02 Sep '05

02 Sep '05

The recent updates to Boost.Serialization code in RC_1_33_0 can provoke a crash at run-time, as shown for instance in http://tinyurl.com/dwu78 (there are other, compile-time problems that I'm not addressing in tihs post.) The problem is located in reset_object_address. The attached patch to libs\serialization\src\basic_iarchive.cpp fixes the problem in my local tests, but as I lack the knowledge to be sure, I'd rather not commit it myself and let it be confirmed to be OK. HTH Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 201a202 > moveable_objects_recent(0), 259a261,265 > if(i >= moveable_objects_end) > return; > if(old_address != object_id_vector[i].address) > // skip to any lower level ones > ++i;

2 1

regex linking problems- no copy constructor or op= for basic_regex<char> ?
by Anthony Knittel 02 Sep '05

02 Sep '05

i've been using the regex library fine to match patterns, but when i changed my objects so the regex object is stored instead of initialised each time, i get linking problems. basically it was working fine as: (simplified code): bool myclass::myfunction(char* testString) { regex mypattern("abcd"); cmatch result; return regex_match(testString, result, mypattern); } but when i changed it to store the mypattern object it came up with linker problems: class myclass { ... regex _mypattern; } void myclass::myclass() { _mypattern = regex("abcd"); } bool myfunction(char* testString) { cmatch result; return regex_match(testString, result, _mypattern); } the complaint seems to be about the copy constructor and op= methods, which are supposedly implemented in the boost_regex library. i'm linking using -lboost_regex-mgw (with the library path defined in LIBRARY_PATH); Anthony

2 1

asio networking proposal
by Christopher Kohlhoff 02 Sep '05

02 Sep '05

As discussed in the "surveying async network io libraries" thread, I'd like to turn asio (asio.sourceforge.net) into a proposal for a boost networking library. As promised, here is a list of areas where asio could use some refinement. I'd appreciate input on: - What people think of the relative importance of the items. For example, what would be required for an initial implementation vs what could or should be left until a later revision. - Whether the proposed changes are of any value. - Any other things that should be on the list. What's Missing ============== * Asynchronous DNS operations. I think it would be reasonable to say that any operation that can block should have an asynchronous equivalent. Should these operations be cancellable (not necessarily portably implementable anyway)? * IPv6 support. I have no experience with IPv6, so it would be great if someone with experience could help out with the design here. * Asynchronous socket close. In certain circumstances closing a socket can block, so it would be reasonable to expect an asynchronous close operation. * Scatter-gather operations (sendv and recvv). * The BSD socket functions sendmsg/recvmsg (which I believe are necessary to support protocols such as SCTP). * SSL/TLS and DTLS support. This would require an external library, and how does that fit in with boost? * Other protocols (PF_UNIX, ...)? * Some type of integration (or support for) a higher-level iostreams-based socket library. * More examples. * Documentation on design and rationale. What Should Be Included and What Shouldn't ========================================== * Obviously asio::thread should not be part of a boost proposal, since that functionality is already covered by Boost.Thread. * The asio::time class should probably not be included, and wherever it's used replaced by Boost.Date-Time. Naming and Structure ==================== * The use of the word "Stream" can be confusing because its existing association in C++ with iostreams. Can anyone suggest an alternative? * Should stream_socket and dgram_socket be merged into a single socket class? There other types of sockets (e.g. sequenced packet) that would require additional classes if the current approach is retained. This would not be required if the BSD socket APIs were covered by a single class. Alternatively, should additional classes be added for the other socket types? * The current separate socket_connector implementation does not correspond to an OS resource, unlike socket_acceptor. This can be problematic, e.g. it prevents a Windows implementation using ConnectEx, and doesn't allow you to set socket options before the connection is established. Therefore I propose adding connect and async_connect operations to socket classes. Should the separate socket_connector be retained? * In designing asio I considered that people may want to customise the demultiplexing strategy associated with each resource. For example the basic_stream_socket template looks like: template <typename Service> class basic_stream_socket; where Service is a "facet" of the demuxer that provides demultiplexing facilities for the socket. The typedef for stream_socket specifies the Service type based on the target platform. However in practice I don't believe this level of customisation is required (to the best of my knowledge no existing asio user customises it), particularly if asio uses the "best" demultiplexing mechanism for each platform. Or another way of looking at it: developers who need this level of control might not use a general purpose networking library anyway. An alternative approach would to have the only template parameter be an allocator (since there is often memory allocation associated with asynchronous operations). For example: template <typename Allocator> class basic_demuxer; template <typename Allocator> class basic_stream_socket; where a stream_socket can only be used with a demuxer that has the same allocator type. The typedefs for demuxer and stream_socket would just use the default allocator. Cheers, Chris

20 65

iterator adapter, little help please?
by Neal Becker 02 Sep '05

02 Sep '05

Previously, I had implemented a nice complex_to_real iterator adapter. It used the older real(z) and imag(z) that return value, not ref. Now it seems it gcc-4.0.1, at least, there are .imag() and .real() that return ref. So I thought I'd update c_to_r adaptor to use them. But, I can't seem to get this to work. Any hints? Here's what I get: g++ -c -I src test2.cc /usr/include/boost/iterator/iterator_facade.hpp: In static member function ‘static typename Facade::reference boost::iterator_core_access::dereference(const Facade&) [with Facade = boost::c_to_r_adapt<__gnu_cxx::__normal_iterator<main()::Complex*, std::vector<main()::Complex, std::allocator<main()::Complex> > > >]’: /usr/include/boost/iterator/iterator_facade.hpp:635: instantiated from ‘Reference boost::iterator_facade<I, V, TC, R, D>::operator*() const [with Derived = boost::c_to_r_adapt<__gnu_cxx::__normal_iterator<main()::Complex*, std::vector<main()::Complex, std::allocator<main()::Complex> > > >, Value = double, CategoryOrTraversal = boost::random_access_traversal_tag, Reference = double&, Difference = ptrdiff_t]’ /usr/lib/gcc/x86_64-redhat-linux/4.0.1/../../../../include/c++/4.0.1/bits/stl_algobase.h:285: instantiated from ‘static _OI std::__copy<_BoolType, std::random_access_iterator_tag>::copy(_II, _II, _OI) [with _II = double*, _OI = boost::c_to_r_adapt<__gnu_cxx::__normal_iterator<main()::Complex*, std::vector<main()::Complex, std::allocator<main()::Complex> > > >, bool _BoolType = false]’ /usr/lib/gcc/x86_64-redhat-linux/4.0.1/../../../../include/c++/4.0.1/bits/stl_algobase.h:317: instantiated from ‘_OI std::__copy_aux(_II, _II, _OI) [with _II = double*, _OI = boost::c_to_r_adapt<__gnu_cxx::__normal_iterator<main()::Complex*, std::vector<main()::Complex, std::allocator<main()::Complex> > > >]’ /usr/lib/gcc/x86_64-redhat-linux/4.0.1/../../../../include/c++/4.0.1/bits/stl_algobase.h:335: instantiated from ‘static _OI std::__copy_normal<true, false>::copy_n(_II, _II, _OI) [with _II = __gnu_cxx::__normal_iterator<double*, std::vector<double, std::allocator<double> > >, _OI = boost::c_to_r_adapt<__gnu_cxx::__normal_iterator<main()::Complex*, std::vector<main()::Complex, std::allocator<main()::Complex> > > >]’ /usr/lib/gcc/x86_64-redhat-linux/4.0.1/../../../../include/c++/4.0.1/bits/stl_algobase.h:387: instantiated from ‘_OutputIterator std::copy(_InputIterator, _InputIterator, _OutputIterator) [with _InputIterator = __gnu_cxx::__normal_iterator<double*, std::vector<double, std::allocator<double> > >, _OutputIterator = boost::c_to_r_adapt<__gnu_cxx::__normal_iterator<main()::Complex*, std::vector<main()::Complex, std::allocator<main()::Complex> > > >]’ test2.cc:12: instantiated from here /usr/include/boost/iterator/iterator_facade.hpp:517: error: invalid initialization of reference of type ‘double&’ from expression of type ‘const double’

2 2

Re: [boost] [program_options] portability patches
by François Dumont 01 Sep '05

01 Sep '05

Ok you got me. I was only trying to build as many boost libs as possible with the msvc-stlport toolset. The fixes were rather easy to make program_options lib build, I should have understood that the reason of those fixes not having been done before is that a buildable library is not necessarily usable. If you think that program_options is totally useless without the as<> syntax support then you can ignore my patches. Maybe a #error reporting this fact would be more obvious and would avoid to people like me to spend some time on it again. Bests

1 0

[serialization] 1.33.0 outdated Jamfile.v2
by Arvid Norberg 01 Sep '05

01 Sep '05

It seems like some source files included in Jamfile are not included in Jamfile.v2 in the serialization library. thanks -- Arvid Norberg

2 1

bizarre test results: foreach, gcc-4_0-darwin
by Eric Niebler 01 Sep '05

01 Sep '05

I need help understanding some of the recent regression results. At http://tinyurl.com/72q3k you can see the most recent Foreach test results. The first and the third columns both purport to be gcc-4_0-darwin, but the results are different! How can that be? Both tests were run today, and I haven't touched the code since yesterday. -- Eric Niebler Boost Consulting www.boost-consulting.com

3 4