- Boost - lists.boost.org

Boost.Context review result
by Vicente BOTET 15 May '11

15 May '11

Hi, this was my first experience as review manager and it has been more difficult than I had expected. Apologies if I forget some important things or I misunderstood others. I hope that the major points have been taken in account. Here it is the result of the Boost.Context review. The library is accepted provisionally and will need to address some mandatory points before a mini review (4/5 days). There were not too much complete reviews (5) but globally all the reviewers voted for acceptation and two subject to some major redesign modifications. I hope I didn't miss somebody. YES Gordon Woodhull YES/Cnd Giovanni Piero Deretta YES Artyom YES Nat Linden YES Phil Endecott YES/Cnd, Jeffrey Lee Hellrung, Jr Thanks to all the review participants Gordon Woodhull, Giovanni Piero Deretta , Artyom, Nat Linden, Holger Grund, Phil Endecott, Jeffrey Lee Hellrung, Jr.. Special thanks to Giovanni Piero Deretta showing some major flaws in the global design and Holger Grund for showing a (possible) major bug on the Windows implementation. I know Oliver that you have already redesigned your library, but if there are points that you have not been addressed yet or have some difficulties addressing them, I will suggest you to work closely with Giovanni, he know well the domain and have a lot of good ideas, and exchange on this ML. You should follow up more closely the discussions during the mini review and even try to get feedback from the ML posting how you see your redesigned library. Point to be addressed before the mini review: Design 1. Separation of the context class in two interface: - A C-like interface that defines a POD struct that is memcpy-able and that can be implemented either using platform libraries, as ucontext, fibers or directly using assembler when a robust implementation is available. The context swap implementation don't need to save the signals as ucontext does. The following is just for illustrations purposes. struct boost_context; typedef void boost_context_fn_t(intptr_t); extern "C" void boost_context_make(boost_context* ctx, boost_context_fn_t * f, intptr_t p, ...); extern "C" void boost_context_swap(boost_context* from, boost_context const* to); extern "C" intptr_t boost_context_destroy( boost_context* fc); boost_context_make is a merge of get_context with make_context + some fields assignations. "A user will have lower expectations from such a low level API and at the same time will give more freedom for other people to implement on top of it higher abstractions as Boost.Corutines, Boost.Fibers ..." - A non-copiable but movable safe context class on top of the low level C-like interface, that will provide modern and efficient C++ interface, that is usable by a user in a safe way. The safe context class would just be one of the client of the C-like interface, other library authors could either use the underlying C-like API directly or the class context depending on wether they need the speed or safety. * The context class will not be templated any more, and the use of type erasure will ensure that. * The constructor will accept any C++ callable, function pointers, functors, ... * At this high level interface, the function provided by the user could throw exceptions, and the library must wrap the user function and needs to store the exception raised and provide an interface to retrieve them. 2. The stack implementation must ensure that the stack is unwound before it is destroyed. A stack should only be safely deallocated if either has been completely unwound or if it doesn't own any resources. A basic stack without protection seems mandatory. For debug purposes it has been required to provide some stack usage functions that allow to know the max size used for example. Implementation 3. The assembler implementation on Windows must be disallowed if the ABI bug reported by Holger is confirmed. As far as Windows provides a fiber implementation that is as efficient as the assembler one, the assembler implementation is not mandatory and the user of the provided Windows fiber is a preferable choice. 4. Most of the 'throw' statements in the context class should actually be asserts. 5. The provided stack should be used to store any context parameters as far as no major impediment is found during the implementation. This will avoid further allocations on the safe context class. Documentation 6. The documentation is very minimalist and should be expanded with a discussion on context switching and use cases. Take care of all the grammar/spelling improvements suggested by the reviewers (It will be great if Jeffrey could review the documentation before the mini-review). Some user land examples should be provided (why not the yield example). 7. The concept of (Movable) Stack must be clearly defined, as it is done in the standard, using expression requirements with semantic constraints. 8. The assembler implementation should be carefully documented, so others could maintain the code and add other implementations if needed. 9. Some performance measure should be added. Providing the number of cycles on each implemented platform would be nice. Build system 10. The default build on a platform must work (It must be ABI compatible with the underlying platform) and take care of the specific features. Of course, the build needs to support cross compiling, so the user should be able to override the default values. Others points that are not required but that can make the library more usable or efficient: 1. The assembler implementations could be simplified if the context itself was represented as a single pointer to the top of the stack. This would save some instructions to move the source address from the stack return address to the context struct and back. 2. Instead of supporting a 'fc_link' a-la ucontext, have the callback function return a new context (it is void now). 'fc_link' is useful only on some limited cases (usually when you have an external scheduler managing your contexts), while the having the callback return the 'next continuation' has more applications (note that fc_link can be implemented easily in term of the continuation returning variant, but the reverse is harder). This will be very useful, for example, to implement some kind of 'exit_to' functionality (unwind the stack and restore another context), a key piece for safe context destruction. 3. Give to boost_context_swap the ability to exchange a parameter with the other context: boost_context_parm_t boost_context_swap( boost_context * ofc, boost_context const* nfc, boost_context_parm_t parm) where boost_context_parm_t is either union boost_context_parm_t { void * ptr; int int_; }; or simply intptr_t; boost_context_swap saves the current context in ocf and restores the context ncf as usual; additionally, if ofc was 'captured' on a call to boost_context_swap, this call will return the value of parm on the original context. This extra parameter is equivalent to the second parameter of longjmp. If ofc was created with boost_context_swap, 'parm' will be an extra parameter to the function. Note that this can be potentially implemented with little or no overhead. 4. Add a variant of boost_context_swap that allows executing a function on the destination context (in this case 'parm' would be passed parameter to this function. This is mostly useful for injecting an exception on the destination context. This can be potentially implemented on top of the existing functionality, but would slow down every context switch; a possible efficient implementation would manipulate the destination stack to add a call to the function on top of it, so that the cost is paid only when required. 5. Add a current context function (thread local). Vicente Review Manager

5 8

Phoenix: error: extra ‘;’ on boost/phoenix/core/environment.hpp
by Vicente BOTET 15 May '11

15 May '11

Hi, There is an error on In file included from ../../../boost/phoenix/core/call.hpp:12, from ../../../boost/conversion/fp/convert_to.hpp:15, from builtins.cpp:16: ../../../boost/phoenix/core/environment.hpp:446: error: extra ‘;’ It seems that the error: extra ‘;’ are on lines 433 and 444 at the end of two functions definitions. Could this be fixed? Thanks, Vicente

5 6

[countertree] New Version
by Francisco José Tapia 15 May '11

15 May '11

Hi this message is to announce the new version of the countertree library. You can find the zip file with the code and the documentation in < http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam…> or if you want a quick look , you can see in my web page < http://fjtapia.webs.com/works/countertree/index.html> Technically this library is an implementation of a binary red-black counter tree. Colloquially is a balanced tree with an additional counter in each leaf. This permit the access to the elements by the position, like in a vector. It is a random access container. If the information stored is unordered, we have the class boost::vectortree. This class have the same interface than a std::vector. The std::vector is very fast O(k) inserting and deleting at end , but very slow O(N) if you must do in other positions . In the vectortree all the operations are O(logN). It is a bite slower than std:vector inserting and deleting at end, but much more faster for to insert and delete in any other position. If the information stored is ordered, you have the classes boost::set, boost::multiset boost::map and boost::multimap. These classes have identical interfaz than the std::set , std::multiset, std::map and std::multimap, and additionally, access by position with the function at(pos). The iterators are random access and have a function pos() which return their position in the container. You can mix safely access by iterators and access by position. The performance of these classes are similar to the classes of the STL. #include <boost/countertree/set.hpp> #include <iostream> int main ( void ) { //------------------------ begin -------------------- boost::set<int> A ; for ( int i = 0 ; i< 100 ; ++i) A.insert(i); for ( int i = 0 ; i < A.size() ; ++i) std::cout<<A.at(i); return 0 ; }; For to show the utility of this, imagine a large unordered file with the information about the employees of a big company. You have indexes implemented with multimaps, with pairs [value, position], and use the upper_bound and lower_bound functions . You need to select the employees in a range of age and weight. With the boost:multimap you can know the number of elements of the selection. In the weight query we found 100 elements and in the age query 10000 elements. To travel the elements of the weight query asking for the age, is faster than the opposite. Tray it. It fast, useful and easy to understand and use,. They are the STL classes with a few additional functions. I had checked this code with GCC (32 and 64) and Visual Studio 2008 (32) and Visual Studio 1010 (32 and 64). Please, if you find any problem, please mail me ( <fjtapia(a)gmail.com>) or if you mail Boost, please insert [countertree] in the head of the message. Some days I have not time to read all messages arrived to my mail, but if I see that I detect and respond first. Francisco Tapia <fjtapia(a)gmail.com>

7 12

Phoenix: is there a Phoenix expression trait?
by Vicente BOTET 15 May '11

15 May '11

Hi, I'm adding a convert_to Phoenix like functor to Boost.Conversion. I would like to use the same name, i.e. convert_to, but the overloads conflict. I would like to use sfinae to choose the correct overloading between template inline typename expression::convert_to, U>::type const convert_to(U const& u); template Target convert_to(Source const& from, boost::dummy::base_tag const& p=boost::dummy::base_tag()) Is there a trait that can be used to detect if the parameter is a Phoenix expression? BTW, I have just based my implementation on the one for static_cast, that uses the detail boost::phoenix::detail::target Could someone explain me why this is needed? Could this detail be moved to the user interface? Best, Vicente

3 2

[context] new version (stack unwinding, ASIO example, ...)
by Oliver Kowalke 14 May '11

14 May '11

Hello, I've reworked on boost.context regarding to the suggestion of the last review (thanks to Vicente as review manager) - but not all requests could be fulfilled. The new lib supports stack unwinding, has examples like C# enumerator concept (yield_return(), yield_break()) and an adapted version of a echo server using stack-less coroutines written by Chr. Kohlhoff and Java continuations. The new version (boost.context-0.7.0.zip) is published on boost vault and the documentation can be read here : http://ok73.ok.funpic.de/boost/libs/context/doc/html/ . Best regards, Oliver

1 0

[BGL] container_gen (was Re: [tree] reviving the tree library)
by Cromwell Enage 14 May '11

14 May '11

--- On Fri, 5/6/11, Erik Erlandson wrote: > My storage models are effectively wrappers around the > underlying containers (the container is a member of > the node type). I originally thought it would be nice > to allow a user to somehow drop in any container they > wanted, but I was unable to find a way to make that > work properly. [snip] > Perhaps container_gen would allow it to be more fully > automated. The idea behind container_gen is indeed to allow users to drop in containers of their choosing by providing their own specializations and selectors. In turn, your node class template needs only to take in the selector type as an additional template parameter. One current limitation that may be important to you is the inability to supply custom allocators as well. I saw in the sandbox that the BGL authors were planning to provide selector templates parameterized by allocator type. I'm wondering how that work is progressing. At any rate, to the BGL authors: I find container_gen to be a useful utility metafunction outside its current home. Would anyone else like to see it become a first-class Boost citizen? Cromwell D. Enage

3 5

[signals2] trunk - vc++ 10 warning about assignment operator
by Edward Diener 13 May '11

13 May '11

An attempt to instantiate a signals2 signal of the form: template <class T> class notification_boost_signal2 { public: boost::signals2::signal<void (const i_some_interface<T> &,boost::optional<T>,T)> sig; }; for notification_boost_signal2<char>, gives the error message in vc++ of: "C:\Programming\VersionControl\boost\boost/signals2/detail/signal_template.hpp(367) : warning C4512: 'boost::signals2::detail::signal3_impl<R,T1,T2,T3,Combiner,Group,GroupCompare,SlotFunction,ExtendedSlotFunction,Mutex>::slot_invoker' : assignment operator could not be generated" There is a huge template trace leading up to this final warning, but before giving it I wonder if anyone knows what it is about ? Perhaps Frank Mori Hess or Douglas Gregor is out there and can tell me what is happening.

3 4

[Block Pointer] multithread help
by Phil Bouchard 13 May '11

13 May '11

Hi everybody, I was wondering if there is anybody familiar enough with Block Pointer that could give me a hand regarding multithread support. Once again the test file is at: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/example/th… The main class I am trying to protect with a mutex is block_header from: https://svn.boost.org/svn/boost/sandbox/block_ptr/boost/block_ptr.hpp Thanks, -Phil

3 7

[multi_array] Is there interest for an [index_list] library?
by Pierre-Andre Noel 13 May '11

13 May '11

(This email has earlier been sent to the wrong list. Thanks to Steven Watanabe for pointing that out.) Dear all, I would like to gauge the interest of the community in a library that can serve 1) as a complement to Boost.MultiArray and 2) as an alternative to Boost.MultiArray. For the first type of use, an example of the candidate library's capabilities is that it makes available a special iterator "it" that allows to browse all the elements of a MultiArray "m". This special iterator has an it.indices() members that returns a "list" Collection of indices (i.e. an IndexList) such that "m(list)" and "*it" are the same elements. This can be useful for functions whose effect on an element of "m" depends on where this element is situated in "m". The second way to use the candidate library is as an alternative to Boost.MultiArray of dynamically chosen (execution time) dimensionality. Moreover, the elements do not necessarily need to be arranged in a multi-dimensional "box", as is the case in a MultiArray. For example, a "simplex" organization of the elements is already implemented. If you are interested to know more, I strongly suggest you to take a look at the example file in sandbox/index_list/libs/index_list/examples.cpp . The library itself is in sandbox/index_list/boost and a readme file (with some details concerning concepts and "priorities") is in sandbox/index_list/libs/README . An automatically generated (Doxygen) documentation is located in sandbox/index_list/libs/index_list/doc/index.html . Sadly, there is no "real" documentation for now. Many thanks for your time. Sincerely, Pierre-André Noël

5 11

boost lib must provide C interface?!
by Oliver Kowalke 13 May '11

13 May '11

Hi, can a boost C++ library be required/forced to provide a C API? Even if the library author doesn't like this idea - because he would be responsible for C stuff. <boost/config.hpp> include <cstddef> which will not be available for a C compiler - maybe this is an indication that boost libs are not required to implement a C-API. regards, Oliver -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

5 6