- Boost-users - lists.preview.boost.org

Asio question
by Amit Sonawane 06 Oct '08

06 Oct '08

Hi, I am using Asio in Boost version 1.36.0 and I have a question regarding recursive call to a completion handler. I have implemented a class similar to the one from the examples of asio acceptor. I would like to know if there is a way to recursively call handle_accept () within handle_accept() and break on condition when the socket is closed. (Please see my comment in the code ). Does Asio allow such implementation or is there another way to handle this condition. #include "server.hpp" #include <boost/bind.hpp> namespace http { namespace server2 { server::server(const std::string& address, const std::string& port, const std::string& doc_root, std::size_t io_service_pool_size) : io_service_pool_(io_service_pool_size), acceptor_(io_service_pool_.get_io_service()), new_connection_(new connection( io_service_pool_.get_io_service(), request_handler_)), request_handler_(doc_root) { // Open the acceptor with the option to reuse the address (i.e. SO_REUSEADDR). boost::asio::ip::tcp::resolver resolver(acceptor_.io_service()); boost::asio::ip::tcp::resolver::query query(address, port); boost::asio::ip::tcp::endpoint endpoint = *resolver.resolve(query); acceptor_.open(endpoint.protocol()); acceptor_.set_option(boost::asio::ip::tcp::acceptor::reuse_address(true) ); acceptor_.bind(endpoint); acceptor_.listen(); acceptor_.async_accept(new_connection_->socket(), boost::bind(&server::handle_accept, this, boost::asio::placeholders::error)); } void server::run() { io_service_pool_.run(); } void server::stop() { io_service_pool_.stop(); } void server::handle_accept(const boost::system::error_code& e) { if (!e) { new_connection_->start(); acceptor_.async_accept(new_connection_->socket(), boost::bind(&server::handle_accept, this, boost::asio::placeholders::error)); //Need to call handle_accept again here e.g. boost::bind(&server::handle_accept, this, boost::asio::placeholders::error)); } } } // namespace server2 } // namespace http Thanks, Anuit Esta mensagem pode conter informação confidencial e/ou privilegiada. Se você não for o destinatário ou a pessoa autorizada a receber esta mensagem, não deverá utilizar, copiar, alterar, divulgar a informação nela contida ou tomar qualquer ação baseada nessas informações. Se você recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperação. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, change, take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.

3 2

[shared_ptr] Cannot include shared_ptr.hpp in a Visual Studio .Net 2003 managed C++ file
by Alice Johnson 06 Oct '08

06 Oct '08

When I include <boost/shared_ptr.hpp> in a file that has Compile as Managed set to Assembly support (/clr), I get: error C2373: 'InterlockedIncrement' : redefinition; different type modifiers C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\WinBase.h(1298) : see declaration of 'InterlockedIncrement' I started with boost version 1.34.1, but have also tried 1.35.0 and 1.36.0 Is there any solution to this? Alice Johnson

4 3

[Asio]: Massive performance degradation with compiler optimization
by Roland Bock 06 Oct '08

06 Oct '08

Hi, I am experimenting with asio in order to replace our current tcp library and stumbled over something weird this morning: The ansynchronous tcp echo server from the examples is much slower (~factor 3) with compiler optimization turned on! http://www.boost.org/doc/libs/1_36_0/doc/html/boost_asio/example/echo/async… For my test I modified the blocking single threaded tcp echo client to send 1000 identical messages of about 100kB length to the server and display the echo (see attachment). with -O0: ========= time ./src/TcpClient localhost 3000 | wc 1000 3000 104459000 real 0m6.072s user 0m5.564s sys 0m0.508s with -O3: ========= time ./src/TcpClient localhost 3000 | wc 1000 3000 104459000 real 0m21.287s user 0m5.756s sys 0m0.164s The optimization has very little effect on the client, though. When performing several runs, the time needed for the experiments varies a lot with -O3, ranging from about 13 seconds to up to 40 seconds. With -O0, the values do not change much (6-7 seconds). Other optimization switches (-O1 or -O2) behave like -O3. I have not tried to turn on/off the single optimization flags like -ftree-dominator-opts yet. Some system information (please do not hesitate to ask for more): Ubuntu 8.04, 64bit g++ 4.2.3 With other parts of boost I checked, opimization works as expected, sometimes with outstanding results: My date parser using spirit gained almost a factor of ten in performance. Any ideas what might be happening with the server? Thanks and regards, Roland

1 0

fast_pool_allocator question
by Ta-Cheng Lin 06 Oct '08

06 Oct '08

Hi : I use fast_pool_allocator and it seems not release memory even I explicitly call boost::singleton_pool<boost::fast_pool_allocator_tag, sizeof(int)>::release_memory(); out put 1. MEM USAGE = 11 MB, 2. MEM USAGE = 35 2. MEM USAGE = 35 2. MEM USAGE = 35 3. MEM USAGE = 35 4. MEM USAGE = 35 <<<--- memory is not released!!! Any suggestions are welcomed. -Todd --- BEGIN ---- #include <boost/pool/pool_alloc.hpp> #include <list> using namespace std; using namespace boost; #include "memusage.cpp" <<-- function to call Unix 'top' //-------------------------------------------------- void func() { list<int, fast_pool_allocator<int> > v; // list<int> v; for (int i = 0; i < 1000000; ++i) { v.push_back(i); } printf("2. MEM USAGE = %d\n", getMemUsage()); } //-------------------------------------------------- int main(int argc, char **argv) { printf("1. MEM USAGE = %d\n", getMemUsage()); func(); func(); func(); /// Exiting the function does NOT free the system memory allocated by the pool allocator // You must call // boost::singleton_pool<boost::pool_allocator_tag, sizeof(int)>::release_memory() // in order to force that printf("3. MEM USAGE = %d\n", getMemUsage()); boost::singleton_pool<boost::fast_pool_allocator_tag, sizeof(int)>::release_memory(); printf("4. MEM USAGE = %d\n", getMemUsage()); return 1; } // from boost doc // If you are seriously concerned about performance, // use fast_pool_allocator when dealing with containers such as std::list, // and use pool_allocator when dealing with containers such as std::vector. -- END --

1 0

[date-time] Should this be an exception
by Larry 06 Oct '08

06 Oct '08

Using 1_35_0 on MSVS .NET 2003 string x("200810051"); try { date d(from_undelimited_string(x)); } catch (exception& e) { } I would have though this would thrown an exception (too many digits in the date) but it didn't. I may have missed it in the doc that the constructor only considers the first 8 digits (for the undelimited case - actually probably the from_undelimited_string function). Or did I miss something else? Larry

1 0

[thread] Synchronisation Across Multiple Condition Variables
by Alex Adranghi 05 Oct '08

05 Oct '08

Dear All, I'd like to ask the floor what is the best way to wait on multiple condition variables, with the first one causing the "aggregated wait" to return with some distinguishable value. --- I'm looking to achieve something akin to .NET's WaitHandle.WaitAny, or a limited Occam ALT. After a quick peak at the source, I believe this would be a non-trivial change to the library. A way around it involves sharing data and wrapping a condition, defining notify() to take a boost:condition_variable. This would notify the condition_variable argument* so that sole observers will be notified, then setting an identifier to a member field, followed by notifying the wrapped general condition itself. The new aggregated wait() would first wait for a notification from the wrapped condition, before retrieving the identifier written to the object to return. Problem is, I don't think this is particularly elegant. Another solution is using threads to wait for each boost::condition_variable, but I don't see this as practical due to obvious overhead. *However this means for notify(), observers of the sole condition have waking preference over observers of the aggregated condition, and there is no way to know if any thread has been woken (in order to determine whether to notify the wrapped boost::condition_variable). --- Thanks for reading this, and answers on a postcard appreciated ;). -- Best regards, Alex Adranghi web: www.alexadranghi.com linkedin: www.linkedin.com/in/alexadranghi mail: mail(a)alexadranghi.com pgp: 0x6770b73f

2 1

[Review] Phoenix review results
by Hartmut Kaiser 05 Oct '08

05 Oct '08

Hi all, the Phoenix review is over and I counted 15 votes, 11 of which vote for acceptance and 4 vote for conditional acceptance. Let me explain. All reviewers stated that the outstanding quality of the library and its documentation fully merit immediate acceptance. There is no direct concern with regard to the library itself. Phoenix V2 is already in the Boost distribution as a Spirit sub-library and has matured for a long time, proving its stability and usability. On the other hand, Phoenix provides functionality already covered by Boost.Bind and Boost.Lambda. It is the general intention to use Phoenix as the development ground for a new unified Boost library in this area. The review discussions revealed quite some details and certain problems which have to be resolved for this merger to happen. Joel has a full list of these details and promised to address all of them before adding Phoenix to the Boost SVN. The library authors made clear from the beginning that the review of the current Version 2 of the library is just a stepping stone towards this goal. At the same time Eric Niebler presented a first version of a Proto based Phoenix rewrite (referenced as Phoenix V3). It is the general consensus to use Phoenix V3 as the basis for further development. At the same time Phoenix V3 exposes the same interface as Phoenix V2 and passes all related tests. This review formally was about Phoenix V2, but largely turned out to be a discussion of the future of Bind/Lambda and how Boost should go forward in this direction. Again, the general consensus here is that a) we need a unified approach to bind, lambda, et.al., and b) Boost users need interface stability and minimal disruption. So here is the review result: The quality of Phoenix warrants immediate acceptance into Boost. OTOH, adding Phoenix to Boost as is introduces yet another library dealing with functional idioms. This possibly increases the confusion around the fact which of the libraries to use, etc. The goal should be to have a clear integration of, and migration path from the existing Boost.Bind and Boost.Lambda libraries before final addition of Phoenix to Boost. We will have a mini review before Phoenix gets merged to SVN to make sure whether the feedback from the v2 review was accommodated. Additionally this review will have to discuss: - the breaking interface changes from v2 - the migration path from boost::bind and lambda to Phoenix - how the interoperability with std::bind is solved (result_of semantics) - C++0x features such as rvalue references and variadic templates - the new extensibility mechanism - unified placeholders and interoperability issues with other Proto-based DSELs (such as Spirit.Qi, Spirit.Karma, and Xpressive) - compile times In general, the review was valuable for what it accomplished. It moved us closer towards a unified Boost library in the domain of functional programming idioms. Thanks to Joel and Dan for the high quality submission and to all participating the discussion for their valuable insights! Regards Hartmut Review Manager

3 2

Re: [Boost-users] [statechart] handling unexpected events
by Robert Mecklenburg 05 Oct '08

05 Oct '08

On 2008-09-18 20:54:11 GMT, Robert wrote: > The only thing I can see is that the unconsumed_event() function is > called with the unexpected event object. What I'd like to do in this > function is: > > 1. Abort my transaction and force the state machine back to the Ready > state. I'm not sure how to do this. I've implemented a hack with an internal event, ResetEvent, that I post. This sort of works, but it executes the exit() member function of the aborted state. I'd rather not, I'm trying to abort the behavior of the current state, not complete it. If there was a way from unconsumed_event() to get the current state object and set a flag in it, I could avoid completing the state behavior with a guard. I can use state_downcast<const T *>() to get a const pointer to my state object, but because it is const I can't set a flag. I cannot seem to get a non-const pointer. > 2. Reprocess the unexpected event if it is a hello or get, discard it > otherwise. I'm not sure how to do this, either. I've discovered that post_event() will enqueue any event for processing after the current react() is finished. Thanks for any insight you can provide, -- Robert

2 1

[statechart] handling unexpected events
by Robert Mecklenburg 05 Oct '08

05 Oct '08

I'm attempting to use StateChart to model a simple socket protocol and I'm having difficulty understanding how to handle protocol errors. I've read the sections on Error handling and two phase exit without gaining much insight. Those sections seem to be concerned with user-written code that cannot complete and thus must throw an exception. The type of error I'm currently concerned with is an unexpected event. For example, in this simple protocol we must first receive a hello before being ready to handle requests. A request returns data and must be followed by a commit, which completes the transaction and returns us to the ready state. (start state) (hello event) -> (ready state) (ready state) (get event) -> (data delivered) (data delivered) (commit event) -> (ready state) My problem is this: how do I detect and recover when I'm in the (data delivered) state and the next event is not a (commit event)? The only thing I can see is that the unconsumed_event() function is called with the unexpected event object. What I'd like to do in this function is: 1. Abort my transaction and force the state machine back to the Ready state. I'm not sure how to do this. 2. Reprocess the unexpected event if it is a hello or get, discard it otherwise. I'm not sure how to do this, either. At a more abstract level, it seems that unconsumed_event() is the only way to deal with an unexpected event and to try to reset the state machine. Is this true? Thanks, -- Robert

2 1

[program_options] Decorating output
by Boris 05 Oct '08

05 Oct '08

When I send options_description to cout I would like to put an empty line between the caption and the options - something like: Allowed options: --help produce help message --compression arg set compression level As : is automatically appended to the caption it's not possible to add \n. Is this what I'm trying to do supported? Another question: Can the argument arg behind the --compression option above be changed to <arg>? I read at http://article.gmane.org/gmane.comp.lib.boost.user/38506 that it's not possible to replace arg with level but maybe putting <> around arg works somehow? Boris

2 1