December 2005 - Boost - lists.boost.org

Asio formal review
by Matthew Vogt 29 Dec '05

29 Dec '05

Firstly, I think the library should be accepted into Boost. I can't see any particular blocking issues that would prevent it being acceptable, and it is high time that some network library is available in boost, to serve as a basis for more abstract facilities. - What is your evaluation of the design? Fine, based on well understood models. - What is your evaluation of the implementation? I haven't looked. - What is your evaluation of the documentation? The documentation is quite good. I would prefer a slightly more discursive style, but the reference information is all there, and the tutorials are a good introduction. I think the examples each need a description, explaining what they exemplify. Also, many of the examples contain some code repetition, where a handler repeats task initiation code also found outside the handler; I think these should be refactored. - What is your evaluation of the potential usefulness of the library? Enormous. - Did you try to use the library? With what compiler? Did you have any problems? No. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Based on reading the documentation only. - Are you knowledgeable about the problem domain? Sockets programming, yes; asynch frameworks, no. I have a number of questions regarding the current proposal (I don't think any of these require changes before acceptance, but I am curious.) Please excuse the lack of structure to these questions :) I don't really follow the intent of the locking dispatcher. It appear to me that it simply achieves the same effect as adding a scoped lock to each dispatched method (each using the same mutex). This gives a small reduction in code, but doesn't immediately strike me as giving the code greater clarity. Also, the shared mutex that would otherwise be used in each method would be available for protecting other related code, while the locking_dispatcher hides the mutex, so that all protected code must be invoked via the demultiplexer. Perhaps a better example than that in the tutorial would make the benefit of the dispatcher clearer? The locking_dispatcher's 'wrap' method seems to be its primary purpose. Since the terminology is a little unnatural, perhaps it could be operator() ? I would like to see a user-supplied handler option for handling genuine errors, not per-call but at a higher level (maybe per-demuxer?) Typically, the response to an error is to close the socket, once open; it would be handy to supply a callback which received enough context to close down a socket, and in all other code to ignore error-handling completely. I do not think EOF should constitute an error, and I would expect that try-again and would-block errors could be safely ignored by the user. Perhaps EOF should be a testable state of the socket, rather than a potential error resulting from 'receive'. Can the proactor be made to work with multiple event sources, with the current interface? For example, wrapping simultaneous network IO and aio-based file IO on POSIX? I wonder how the demuxer would be incoporated into a GUI event-loop-based program, particularly in toolkits which mandate that GUI updates can occur from a single thread only? Perhaps the 'run' member function could be called in a non-blocking fashion? Or perhaps the demuxer could queue ready handler callbacks for later execution, rather than invoking them directly? Then the GUI thread could execute all pending handler functions on idle. I believe there should be an automatically managed buffer-list class, to provide simple heap-based, garbage-collected buffer management, excluding the possibility of buffer overruns and memory leaks. Perhaps the one in the Giallo library could be used without significant modification, and supported by the asio buffer primitives. Also, this abstraction should be used in tutorials; although it is useful and practical to support automatically allocated buffer storage, it shouldn't be needlessly encouraged. I also would like to request some commentary (in the library documentation) on future developments that are out of scope for the current proposal. Given the late juncture at which we're looking at bringing network programming into boost, I think it's important to consider desirable extensions, and how the current proposal will support them. Much of this will be discussed in the review, of course. One thing I would like to see (even in Asio itself) is a simplest-possible layer over the bare sockets layer, which took care of resource management and the intricacies of sockets programming. Ideally, this would leave an interface comparable to asynch IO programming in python and the like, suitable for the smallest networking tasks. Other, more complicated layers, such as socketstreams and compile-time filter-chaining as in Giallo, could be provided as libraries built on Asio. Matt

5 24

[review] Asio formal review.
by Rene Rivera 28 Dec '05

28 Dec '05

I vote to *not* accept Asio as a Boost library. This is based on some specific deficiencies in design/implementation and documentation. Hence if those are remedied I would be willing to change my vote. What is your evaluation of the design? Fair -- The overall separation of responsibilities is good and provides for considerable reuse. And possibly independent use of many of the facilities. Unfortunately many of the interactions and dependencies between the parts are not clear. In many situation I had to resort to reading through the implementation to figure out the various connections. Even though I can see how I would use the library in some tasks there are others I just don't see how something could be implement in an efficient manner. (More below on my specific use case) What is your evaluation of the implementation? Good -- For the given design the implementation is clear and easy to follow. But because of some particular design choice(s) there are some serious performance deficiencies which I would think prevent its use in the one area where the library was ostensibly design to be used, high performance servers. What is your evaluation of the documentation? Insufficient -- Even though I'm a proponent of Dox style automated documentation in this case the Dox reference documentation is insufficient in describing how the various operations work. The supporting design, tutorials, and examples I don't feel provide sufficient background to understand how the pieces connect and react with each other. Specifically the example code should at minimum explain why calls are done. In summary, either the reference docs need to improve significantly, or the non-reference docs need to take up the slack. What is your evaluation of the potential usefulness of the library? Good -- Even with my concerns about efficiency I can see the use in the wider connection based client/server domain where response efficiency is a minor concern. Did you try to use the library? No. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? In-depth -- I read a good portion of the documentation, and various parts of the implementation with a particular use case in mind. Are you knowledgeable about the problem domain? Yes. I have done some form of networking programming for the past 10 years. In the form of HTTP handlers, Game multiplayer games, and most recently client/server version control system. Now some details about my use case and my performance concern... I am looking at Asio to provide the socket handling for one of my current projects, the version control system. I'm in the middle of rewriting the networking aspect of it from the classic thread per client model to an async endpoints and routers star to star virtual LAN topology with a custom reliable message protocol based on UDP. This means that since I'm writing my own router I need the best performance I can get. But to give some minimal concrete numbers... Given a single gigabit line, a minimal example as a server is likely going to have multiple lines, and the most favorable situation of handling full 64K UDP packets one would need to handle about 1500 messages a second (or 2/3 of a millisecond per message). But in practice it would have to be faster than that. This means minimizing the most expensive steps, i.e. memory allocations. Currently AFAICT in order to use the async operations asio requires a model which allocates a new handler for each message received. This might be fine for many situations where those handlers will change from message to message. But for my use case I have only one handler that needs to get called for *any* message that comes in. In the asio case it means that for each message I received it would: remove the handler from the demuxer map, call the handler, which would do my custom parsing and routing, and push a new async_receive of myself (which creates a new handler object and inserts it again into the demux map). This is clearly suboptimal, and will result in considerable performance degradation. To refer to some concrete code, one can look at the Daytime.6 tutorial which does basically that procedure. Of course it would be awesome if Christopher would come out and tell me I'm stoned and point out how to achieve the optimum I need. Barring that for me to use Asio for my project I would end up creating patched versions of epoll_reactor, kqueue_reactor, reactor_op_queue, reactive_sokect_service, and win_iocp_socket_service (maybe more). Such hacking of implementation classes to me means a serious design failure. Here's to hoping I'm wrong ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

14 58

[foreach] cheap_copy crisis?
by MB 28 Dec '05

28 Dec '05

Hi, Under VC++7.1, I was surprised that a class derived from 'boost::iterator_range' was almost copied by BOOST_FOREACH. ('boost::noncopyable' works!) I think such a range that is noncopyable but derived from iterator_range is valid, isn't it ...? I think it could be dangerous if users can't find cheap_copy-customization. Regards, MB http://p-stade.sourceforge.net/

4 15

[filesystem] typo in doc/operations.htm
by Caleb Epstein 28 Dec '05

28 Dec '05

On the page http://boost.org/libs/filesystem/doc/operations.htm, in the "rename" section: "Note: Some operating systems with multiple roots<http://boost.org/libs/filesystem/doc/index.htm#multi-root_filesystem>do not allow *rename* operations between roots, and such an attempted *rename* with throw a * filesystem_error <http://boost.org/libs/filesystem/doc/exception.htm>*exception.." Should read: * *"Note: Some operating systems with multiple roots<http://boost.org/libs/filesystem/doc/index.htm#multi-root_filesystem>do not allow *rename* operations between roots, and such an attempted *rename* will throw a * filesystem_error <http://boost.org/libs/filesystem/doc/exception.htm>*exception." E.g. change "with" to "will". Note also that there is an extra period at the end of the sentence. -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

[Boost-bugs] [ boost-Support Requests-1391956 ] Embedded python won't compile
by SourceForge.net 28 Dec '05

28 Dec '05

Support Requests item #1391956, was opened at 2005-12-28 05:15 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=1391956&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: Embedded python won't compile Initial Comment: I followed the tutorial about embedding at http://www.boost.org/libs/python/doc/tutorial/doc/html/python/embedding.htm… but I am now faced with some errors (VC++ 6.0, latest Service Pack running on Windows 2000 SP4). The errors: Compiling... StdAfx.cpp Compiling... pytest.cpp f:\pytest\pytest.cpp(10) : error C2065: 'object' : undeclared identifier f:\pytest\pytest.cpp(10) : error C2146: syntax error : missing ';' before identifier 'main_module' f:\pytest\pytest.cpp(10) : error C2065: 'main_module' : undeclared identifier f:\pytest\pytest.cpp(11) : error C2065: 'handle' : undeclared identifier f:\pytest\pytest.cpp(11) : error C2059: syntax error : '>' f:\pytest\pytest.cpp(13) : error C2146: syntax error : missing ';' before identifier 'main_namespace' f:\pytest\pytest.cpp(13) : error C2065: 'main_namespace' : undeclared identifier f:\pytest\pytest.cpp(13) : error C2228: left of '.attr' must have class/struct/union type f:\pytest\pytest.cpp(15) : error C2059: syntax error : '>' Error executing cl.exe. pytest.exe - 9 error(s), 0 warning(s) The code: pytest.cpp ========== // pytest.cpp : Defines the entry point for the console application. // #include "stdafx.h" int main(int argc, char* argv[]) { Py_Initialize(); object main_module(( handle<>(borrowed(PyImport_AddModule("__main__"))))); object main_namespace = main_module.attr("__dict__"); handle<> ignored((PyRun_String( "hello = file('hello.txt', 'w')\n" "hello.write('Hello world!')\n" "hello.close()" , Py_file_input , main_namespace.ptr() , main_namespace.ptr()) )); Py_Finalize(); return 0; } StdAfx.cpp ========== // stdafx.cpp : source file that includes just the standard includes // pytest.pch will be the pre-compiled header // stdafx.obj will contain the pre-compiled type information #include "stdafx.h" // TODO: reference any additional headers you need in STDAFX.H // and not in this file StdAfx.h ======== // stdafx.h : include file for standard system include files, // or project specific include files that are used frequently, but // are changed infrequently // #if !defined(AFX_STDAFX_H__14167E34_D56C_4B80_BB18_4CB7F7E8E058__INCLUDED_) #define AFX_STDAFX_H__14167E34_D56C_4B80_BB18_4CB7F7E8E058__INCLUDED_ #if _MSC_VER > 1000 #pragma once #endif // _MSC_VER > 1000 #define WIN32_LEAN_AND_MEAN // Exclude rarely-used stuff from Windows headers #include <stdio.h> #include "boost\python.hpp" using namespace std; // TODO: reference additional headers your program requires here //{{AFX_INSERT_LOCATION}} // Microsoft Visual C++ will insert additional declarations immediately before the previous line. #endif // !defined(AFX_STDAFX_H__14167E34_D56C_4B80_BB18_4CB7F7E8E058__INCLUDED_) Libs ==== kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib python24.lib boost_python.lib Please help, I would VERY much appreciate it- good job with all the hard work on Boost.Python! My email address is jamclx(a)gmail.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1391956&group_… ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[asio] what happens to outstanding operations when demuxer::interrupt called?
by Andrew Schweitzer 28 Dec '05

28 Dec '05

The doc seems to imply that if demuxer::reset() and demuxer::run() are called again, then outstanding operations will in fact be executed. Is this true? Are there general design philosophies out there for handling things that happen way too late because the loop was paused? One system I worked on just fired all the stale timers at once, which I think what asio does. In the system I worked on, no effort was made to check whether the timer was firing hours too late. Would it be reasonable to modify the timer completion handler to accept the amount of time "overdue" the current call of the handler is? This would at least allow the handler to check, but maybe that's too complicated. There appears to be no general way to toss all work outstanding, is this correct? I assume that's because it's hard to do so portably for all services. On the other hand, it seems like maybe just deleting all your deadline_timer or stream_socket objects would cause them all to be cleaned up.

2 1

[boost.test] Non-conforming operator new, AFAICT
by Markus Schöpflin 28 Dec '05

28 Dec '05

Hello, boost.test currently contains an assortment of new operators which IMO are not conforming to the C++ std. The implementation basically looks like this: p = std::malloc(n); if (!p) throw std::bad_alloc(); This ignores the fact the std::malloc() is allowed to return either 0 or some unique pointer on zero sized requests, whereas a C++ allocation function _must_ return a unique pointer for each zero sized request. If I'm correct, this could be easily fixed by changing all occurences of "p = std::malloc(n)" to "p = std::malloc(n ? n : 1)" or something similar. Regards, Markus

4 8

[Boost-bugs] [ boost-Bugs-1391875 ] _GLIBCXX_DEBUG fails on 1.33.1 - bug or design?
by SourceForge.net 28 Dec '05

28 Dec '05

Bugs item #1391875, was opened at 2005-12-28 12:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1391875&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: regex Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rafal Wijata (ravpl) Assigned to: John Maddock (johnmaddock) Summary: _GLIBCXX_DEBUG fails on 1.33.1 - bug or design? Initial Comment: Results in segfault (on vector destructor) Was ok(and still is) on 1.33.0 Compiled with gcc 4.0.2 on RHELAS4 with g++ -rdynamic -export-dynamic -D_GLIBCXX_DEBUG -g -lboost_regex -o test test.cpp sourcefile incuded. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1391875&group_… ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[variant] Proposal for compile time checked getter
by Zara 28 Dec '05

28 Dec '05

Dear all, During a redesign, I began using boost::variant, and I detected that trying to get a value of a type not included in variant type-list resulted in run-time error (cast or null pointer). I feel that a variant should only try to return a valid type from its type-list, otherwise giving a compiler error, and reserve runttime errors for that case when someone tries to get a value from a type contained in the typelist, but not the actual type contained in the actual object. In such a way, I have made a little redesign on boost::get and called it boost::checked_get: namespace boost { template <typename U, BOOST_VARIANT_ENUM_PARAMS(typename T) > inline typename add_pointer<U>::type checked_get( boost::variant< BOOST_VARIANT_ENUM_PARAMS(T) >* operand BOOST_VARIANT_AUX_GET_EXPLICIT_TEMPLATE_TYPE(U) ) { typedef boost::variant< BOOST_VARIANT_ENUM_PARAMS(T) > Variant; /* throw a compile-time error if type is not contained on type list */ BOOST_STATIC_ASSERT((!is_same< typename mpl::find<typename Variant::types,U>::type, typename mpl::end<typename Variant::types>::type>::value)); typedef typename add_pointer<U>::type U_ptr; if (!operand) return static_cast<U_ptr>(0); detail::variant::get_visitor<U> v; return operand->apply_visitor(v); } } // end of addition to namespace boost And, of course, the rest of the templates needed for const *, ref and const&.. I think it would be interesting to include it in boost libraries. In fact, I use it intensely. Best regards, -- Zara PS Forgive me for my bad english.

1 0

[asio] Why "const mutable_buffers &" in interfaces?
by Mats Nilsson 28 Dec '05

28 Dec '05

Hi Just a question asking to clarify the use of "const Mutable_Buffers &mutable_buffers" in the calls to some of the functions, e.g stream_socket::receive(const Mutable_Buffers &buffers, message_flags flags). To me, this is not logical, since I'd expect a receive function to actually modify the stuff I send into it, and the const qualifier doesn't seem to allow this. If it needs to be this way, you might want to explicitly explain this design choice somewhere close to where it is used. Also the reference documentation for asio::mutable_buffer seems to have a copy-paste bug; its detailed description includes "The const_buffer class provides ...", or am I missing something? Mats

3 2