- Boost - lists.boost.org

Trouble with asio while compiling libtorrent
by the-real-sim＠gmx.de 29 Sep '06

29 Sep '06

Hello List, i tried to compile libtorrent (libtorrent.sf.net) but i get the following error message: ../include/libtorrent/asio/socket_base.hpp:432: error: '__invalid_size_argument_for_IOC' cannot appear in a constant-expression ../include/libtorrent/asio/socket_base.hpp:432: error: template argument 1 is invalid ../include/libtorrent/asio/socket_base.hpp:455: error: '__invalid_size_argument_for_IOC' cannot appear in a constant-expression ../include/libtorrent/asio/socket_base.hpp:455: error: template argument 1 is invalid ../include/libtorrent/asio/basic_stream_socket.hpp: In member function 'size_t asio::basic_stream_socket<Protocol, Service>::in_avail()': ../include/libtorrent/asio/basic_stream_socket.hpp:786: error: request for member 'get' in 'command', which is of non-class type 'int' ../include/libtorrent/asio/basic_stream_socket.hpp: In member function 'size_t asio::basic_stream_socket<Protocol, Service>::in_avail(Error_Handler)': ../include/libtorrent/asio/basic_stream_socket.hpp:808: error: request for member 'get' in 'command', which is of non-class type 'int' make[2]: *** [allocate_resources.lo] Error 1 someone from the libtorrent list said i should post here. the ./configure script from libtorrent ran without a hitch. here's what's on my G3 Powerbook: Ubuntu 6.06 LTS ubuntu boost version: 1.33.1-2 any hints/tips/ideas welcome :) thanks in advance, #Simon -- GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist! NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl

1 0

Problem with conditional variables in boost
by Mariusz Kedzierawski 29 Sep '06

29 Sep '06

Hi I think there is a problem in implementation of function: void condition_impl::notify_one() (with BOOST_HAS_MPTASKS beeing defined - apple version) in file condition.cpp There is no mutex release before leaving that function in one place: (The same problem is in fuction notify_all) //------[ BEGIN ]------------------------------------ void condition_impl::notify_one() { unsigned signals = 0; OSStatus lStatus = noErr; lStatus = safe_enter_critical_region(m_mutex, kDurationForever, m_mutex_mutex); assert(lStatus == noErr); if (m_waiting != 0) // the m_gate is already closed { if (m_blocked == 0) { lStatus = MPExitCriticalRegion(m_mutex); assert(lStatus == noErr); return; } ++m_waiting; --m_blocked; /************************************************/ /************************************************/ There is no MPExitCriticalRegion(m_mutex) here ! /************************************************/ /************************************************/ } else { lStatus = safe_wait_on_semaphore(m_gate, kDurationForever); assert(lStatus == noErr); if (m_blocked > m_gone) { if (m_gone != 0) { m_blocked -= m_gone; m_gone = 0; } signals = m_waiting = 1; --m_blocked; } else { lStatus = MPSignalSemaphore(m_gate); assert(lStatus == noErr); } /************************************************/ /************************************************/ Solution could be putting "}" here instead of after ongoing while (signals) {...} /************************************************/ /************************************************/ lStatus = MPExitCriticalRegion(m_mutex); assert(lStatus == noErr); while (signals) { lStatus = MPSignalSemaphore(m_queue); assert(lStatus == noErr); --signals; } } } //------[ END ]------------------------------------ Second problem is in file condition.hpp //------[ BEGIN ]------------------------------------ template <typename M> void do_wait(M& mutex) { /... m_impl.enter_wait(); //... lock_ops::unlock(mutex, state); /************************************************/ /************************************************/ Unlocking mutex and hanging on semaphore should be atomic operation and here it is not (notification can be lost here (becouse of switching between threads) and thread can than wait for it forever). /************************************************/ /************************************************/ m_impl.do_wait(); //... lock_ops::lock(mutex, state); //... } //------[ END ]------------------------------------ Please correct me if I am wrong :) -- Mariusz Kedzierawski M(dot)Kedzierawski(a)gmail.com

4 6

[thread, config] Multithread for HP-UX aCC6 V2?
by Vladimir Prus 29 Sep '06

29 Sep '06

On Friday 29 September 2006 12:02, Roland Schwarz wrote: > In the regressions for HP-UX aCC6 V2 > > HP-UX aCC6 V2 > http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/t >hread.html > > I can see a error message: > > # error "Compiler threading support is not turned on. Please set the > correct command line options for threading: -mt" This is bogus error, since the command line is: aCC -AA -mt +DD64 -c -DBOOST_ALL_NO_LIB=1 -DBOOST_THREAD_BUILD_DLL=1 +d -g -mt -I".." -o "......../test_barrier.o" "../libs/thread/test/test_barrier.cpp" and contains -mt as many as *two* times ;-) > What can be done about this? I think that either Boost.Thread or Boost.Config do not notice that threading is enabled. I'm copying this message to boost-devel, probably somebody can suggest the fix. - Volodya -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build V2: http://boost.org/boost-build2

3 2

Channel (distributed message passing and event dispatching) redesigned and implemented in boost
by Yigong Liu 29 Sep '06

29 Sep '06

Last night i sent out this email as reply to some old email. I didnot see it appearing in my gmail mbox this morning. So i am resending it and hoping to get more comments on design. Sorry for the duplication. Channel is a Namespace based C++ template framework for distributed message passing and event dispatching. It is redesigned and reimplemented based on Boost. Initial design document and major framework code is available from sourceforge: http://channel.sourceforge.net/boost_channel/doc/design.html http://sourceforge.net/projects/channel Coding and testing is done in linux (Fedora Core 3 &4). Havent try it on Windows yet. Comments and corrections on the design are highly appreciated. Attached please find a introduction of the library. Thanks Yigong ----------------------------------------------------------------------------------------------------- In Unix and most OSes, file systems allow applications to identify, bind to and operate on system resources and entities (devices, files,...) using a "name" (path name) in a hierarchical namespace (directory system) which is different from variables and pointers in flat address space. In Boost.Signal and libsigc++, callbacks/slots objects can be connected explicitly to specific signals objects to allow synchronous event dispatching. Channel is a C++ template library to provide namespaces for asynchronous, distributed message passing and event dispatching. Message senders and receivers bind to names in namespace; binding and matching rules decide which senders will bind to which receivers; then message passing and event dispatching could happen among bound senders and receivers. Channel's signature: template < typename idtype, typename platform_type = boost_platform, typename synchpolicy = mt_synch<platform_type>, typename executor_type = abstract_executor, typename name_space = linear_name_space<idtype,executor_type,synchpolicy>, typename dispatcher = broadcast_dispatcher<name_space,platform_type> > class channel; Various namespaces (linear/hierarchical/associative) can be used for different applications. For example, we can use integer ids as names to send messages in linear namespace or we can use path name ids to send messages in hierarchical namespace; User can configure namespace easily by setting a channel template parameter. Channel's other major components are dispatchers; which dispatch messages/events from senders to bounded receivers. Dispatcher is also a channel template parameter. The design of dispatchers can vary in several dimensions: - how msgs move: push or pull; - how callbacks executed: synchronous or asynchronous. Sample dispatchers includes : synchronous broadcast dispatcher, buffered asynchronous dispatchers,... Namespace and dispatchers are orthogonal; they can mix and match together freely; just as STL algorithms can be used with any STL containers by means of the iterator range concept, Namespace and dispatchers can be used together because of the name binding set concept. By combining different namespace and dispatching policies, we can achieve various models: - synchronous event dispatching - associative space model similar to tuple space - asynchronous messaging model similar to Microsoft CCR (Concurrency Coordination Runtime) Similar to distributed files systems, distributed channels can be connected or "mounted" to allow transparent distributed message passing. Filters and translators are used to control namespace changes. Channel is built on top of Boost facilities: - boost::shared_ptr for message/event data life-time management - boost::bind, boost::function for callback - boost::thread for synchronization - boost::serialization for message marshaling/demarshaling - Boost.Asio and Boost.Shmem are used to build transports among remote channels.

3 3

[Boost-bugs] [ boost-Patches-1430820 ] [thread] [tss_hook.cpp] Suppress MSVC CRT memory leak report
by SourceForge.net 29 Sep '06

29 Sep '06

Patches item #1430820, was opened at 2006-02-13 18:49 Message generated for change (Comment added) made by speedsnail You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1430820&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: Closed Resolution: None Priority: 5 Submitted By: Kevin J Bluck (kbluck) Assigned to: Roland Schwarz (speedsnail) Summary: [thread] [tss_hook.cpp] Suppress MSVC CRT memory leak report Initial Comment: MSVC CRT memory debugger pedantically complains about an unreleased singleton allocation. Although the consensus is that this is a harmless annoyance, it does cause some concern for MSVC users who don't know what is happening. Issue discussed in this Boost mailing list thread: http://lists.boost.org/boost-users/2005/08/13538.php Attached is a patch for tss_hook.cpp, which uses the function _CrtSetDbgFlag to temporarily turn off heap allocation tracking for the particular allocation in question. It should have no effect except on MSVC debug builds. On my configuration (msvc-8_0) it eliminates the leak warnings. ---------------------------------------------------------------------- >Comment By: Roland Schwarz (speedsnail) Date: 2006-09-29 08:41 Message: Logged In: YES user_id=541730 The issue has been fixed in 1.34 and HEAD, altough differently than the patch suggests. I cannot see that the suggested patch is MT safe. ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2006-04-02 05:23 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Roland Schwarz (speedsnail) Date: 2006-03-18 21:12 Message: Logged In: YES user_id=541730 I will look into this, since AFAIK Michael Glassford currently is not available. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1430820&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Cvs nightly?
by Sohail Somani 29 Sep '06

29 Sep '06

Is there a cvs nightly zip of the boost tree? Thanks, Sohail

2 1

fusion, asio, mpi and other new libraries.
by Janek Kozicki 29 Sep '06

29 Sep '06

I wanted to ask if those new libraries (fusion,asio,mpi) are to be in next_next boost release? (1.35) Is there somewhere a list of those libraries waiting for inclusion? I'm asking because they are certainly not a part of library documentation: http://www.boost.org/libs/libraries.htm I just wanted to check, maybe there is some library I don't know about. -- Janek Kozicki |

2 2

Re: [boost] [parameter] why are keywords non-const?
by Sohail Somani 28 Sep '06

28 Sep '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams > >> What am I missing? > > > > s/mutable type/immutable type/? > > No :)

1 0

Re: [boost] [parameter] why are keywords non-const?
by Sohail Somani 28 Sep '06

28 Sep '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams > That's just what adding const to a well-behaved > mutable type does: makes all mutating operations unavailable. > > What am I missing? s/mutable type/immutable type/?

2 1

[parameter] why are keywords non-const?
by Eric Niebler 28 Sep '06

28 Sep '06

The BOOST_PARAMETER_KEYWORD(tag, name) macro expands, in part, to something like: keyword<tag::name> & name = ...; Shouldn't this be: keyword<tag::name> const & name = ...; ^^^^^ What is the reason for using a non-const ref here? These things are not mutable. In fact, it is causing me problems. Consider a placeholder type with an implicit conversion operator: struct default_constructed_t { template<typename T> operator T() const { return T(); } }; default_constructed_t const default_constructed = {}; BOOST_PARAMETER_KEYWORD(tag, value) Now, when I do this: "value = default_constructed;" I get this error: main.cpp:306: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second: /cygdrive/c/boost/consulting/svn/main/boost/1.33.1/backports/boost_1_33_1/boost/parameter/ keyword.hpp:59: note: candidate 1: const typename boost::parameter::aux::tag<Tag, const T>::type boost::parameter::keyword<T>::operator=(const T&) const [with T = default_constructed_t, Tag = tag::value] /cygdrive/c/boost/consulting/svn/main/boost/1.33.1/backports/boost_1_33_1/boost/parameter/ keyword.hpp:32: note: candidate 2: boost::parameter::keyword<tag::value>& boost::parameter::keyword<tag::value>::operator=(const boost::parameter::keyword<tag::value>&) Had the keyword object been const, the call would not have been ambiguous. -- Eric Niebler Boost Consulting www.boost-consulting.com

2 5