- Boost - lists.boost.org

[Review.Coroutine] Vicente's review
by Vicente J. Botet Escriba 13 Sep '12

13 Sep '12

Hi, I understand that Oliver is busy as all of us and that it is better to provide first the minimal and well designed scope he is confident with. I expect however that Oliver will add soon symmetric coroutines based on the work done by Giovanni in a near future. - What is your evaluation of the design? I have some suggestions about changing the interface, but I'm not sure all of them could be implemented in an efficient way. * The use of thecoro_t::self_t & self parameter makes too much noise. This parameter must be forwarded to any function that could yield the coroutine. An alternative design using a thread specific pointer could allow to access the current coroutine int f20() { typedef this_coroutine<int(void)> this_coro; this_coro::yield(5); } Is the rationale for using self_t to get better performances? Maybe both interfaces could be provided. * There is an asymmetry between the value returned the last time and the others. self.yield( i); // OTHERS return i; // LAST This asymmetry forces the user to manage the last return in a specific case, changing the readability of the code. I would prefer coroutine function returns void. voidfn( coro_t::self_t & self) { self.yield(1); self.yield(2); } * If this is not adopted, the implementation should check at compile time that the return type of the coroutine function is the one of the signature. * The access to the actual coroutine parameters is asymmetric, letting access to old actual parameters that can point to objects that have already been destroyed. Maybe the self_t object could take care of this (or this_coroutine). We can use a get<> function to give access to the actual parameters. int f20(coro_t::self_t & self) { self.yield(2*self.get<0>()); } int f20() { typedef this_coroutine<int(int)> this_coro; this_coro::yield(2*this_coro::get<0>()); } Or even use some kind of bind parameter int f20(coro_t::self_t & self) { int i; int j; self::bind(i, j); self.yield( i + j ); } int f20() { int i; int j; typedef this_coroutine<int(int)> this_coro; this_coro::bind(i, j); this_coro::yield( i + j ); } If bind is adopted, the implementation could use it to store directly the actual parameters, instead of needing to store them in the self_t instance and them returning them when yield is called. */As// Boost.Coroutine is able to transfer user exceptions, and there is no difference between calling to coroutine<>::self_t::yield_break()/ and throwing/coroutine_terminated,/both (/coroutine<>::self_t::yield_break()/ and throwing/coroutine_terminated)/be removed from the library. The same applies for generators. * noexcept specifier should be added to class coroutine { // ... coroutine() BOOST_NOEXCEPT; coroutine( coroutine && other) BOOST_NOEXCEPT; coroutine & operator=( coroutine && other) BOOST_NOEXCEPT; explicitoperator bool() const BOOST_NOEXCEPT; bool is_complete() const BOOST_NOEXCEPT; //... }; void swap( coroutine & l, coroutine & r) BOOST_NOEXCEPT; The same applies to generator. * Type-erase on the Allocator parameter as the standard std::packaged_task does. * Make coroutine/generator classes to follow the allocator aware standard protocol adding the constructor with the standard allocator. A specializations of the use_allocator template should be added for this purpose. * Moving some of the coroutine/generator optional parameters to a coro::attributes class could simplify the interface std::size_t size = ctx::default_stacksize(), flag_unwind_t do_unwind = stack_unwind, bool preserve_fpu = true, * The lib shouldn't throw when preconditions are not satisfied, assert should instead. * It is a shame that the library can not support completely move semantics for the coroutine parameters, as the used boost::tuple don't support it yet. I would like this point be addressed before the first release so that there is no break in the interface when this will be solved either using boost::tuple, boost::fusion::tuple or std::tuple. At a last resort the library could either define a macro that allows to parameterize the tuple implementation, or alternatively it could implement a wrapper that forwards to the best implementation. * As others have noted, providing a view of a generator as an output iterator will be welcome. Viewing it as a range will be also appreciated. BTW, I don't like the alternative using optional as the result of a generator. Following the output iterator concept the access is defined only if the generator has not finished. - What is your evaluation of the implementation? I have not a deep opinion as I have not found the time to inspect it. At first glance, it seems that the inheritance hierarchy is deeper than needed and the use of the pre-processor to manage with variadic templates hides a possible good design (as it is usual in those cases). Maybe now that most of the c++ compilers support them, using the preprocessor is less imperative. - What is your evaluation of the documentation? I find the documentation a little bit sparse and contain a lot or typos and minor errors. I would appreciate if the original Boost.Coroutine documentation from Giovannii were not lost, at least for Motivation and Tutorial parts. I would appreciate also if the documentation include the rationale to don't include symmetric coroutines and show how the current library can be used to solve the problems the missing features provide, why not as examples. * showing the signature in the documentation will be more informative. template< typename Signature, typename Allocator = ctx::stack_allocator >class coroutine; template< typename R, typename ...ArgTypes, typename Allocator > class coroutine<R(ArgTypes...)> { public: class self_t { public: tuple<ArgTypes...>yield( R); void yield_break(); }; * documentation for the following constructor is missing in the reference template< typename Fn > coroutine( Fn && fn, std::size_t size = ctx::default_stacksize(), flag_unwind_t do_unwind = stack_unwind, bool preserve_fpu = true, Allocator alloc = Allocator() ); *The example typedef boost::coro::coroutine< void(int) > coro_t; void f( coro_t::self_t & self, int i) { ... self.yield(); ... } coro_t c( boost::bind( f, _1) ); c( 7); doesn't compiles. It should be something like coro_t c( boost::bind( f, _1, _2) ); BTW, I don't see the need to use boost::bind in this case, as coro_t c( f ); works as well. The superfluous uses of bind in the documentation should be removed: - What is your evaluation of the potential usefulness of the library? Very useful. coroutines and generators are some useful constructions that are missing in the language. - Did you try to use the library? With what compiler? Did you have any problems? Yes. I used gcc-4.2.1,4.6.0, 4.7.0,clang2.9 andclang-3.0 on darwin. I had no problem running the provided examples and tests. I have written some examples. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I have read the documentations of Oliver and Giovanii libraries, followed the review and used the library. - Are you knowledgeable about the problem domain? From the theoretical point of view, yes. Never used in practice. Finally, my vote is YES. Even if the current interface has some drawbacks that should be mentioned in the documentation, I think I Boost.Coroutine is already useful and should be accepted into Boost. Best, Vicente P.S. Maybe I have forgotten to include some of the remarks I did on preceding posts.

4 11

[optional] using gdb to inspect optional value
by Pedro Larroy 13 Sep '12

13 Sep '12

Hi Is there a way to inspect an optional with gdb? I had to remove the usage if boost::optional as it caused me trouble to inspect the value. Thanks. Pedro.

2 1

[asio] New feature: timeout for poll()
by Max Che 13 Sep '12

13 Sep '12

Hello. My previous letter contained errors. Here is another letter. I want to use win_iocp_io_service::poll() with timeout. poll() + timeout => poll() functional and free waitable timer! GetQueuedCompletionStatus() (and epoll(), kqueue()) allows to use that. Can anyone add (restore) this feature?

1 0

[shared_ptr] Patch adding weak_use_count and weak_from_this
by Brent Lewis 12 Sep '12

12 Sep '12

These are useful for debugging, similarly to shared_ptr::use_count. Specifically, you can check for dangling pointers by replacing ordinary pointers with weak pointers, and checking the count inside a destructor. The patch is for boost 1.49 and is attached.

1 0

[build] 1.49 unable to bootstrap boost
by yuri kilochek 12 Sep '12

12 Sep '12

Not sure if this goes here. On Windows 7, when I try to do bootstrap on a freshly unzipped boost 1.49 at the root directory, I get the following output: Building Boost.Build engine But that is as far as it gets before os terminates whatever it is doing with this (roughly translated from russian): **** STACK SIZE EXCEEDED **** **** WHILE PERFORMING RECURSION IN BATCH MODE **** Recursion depth=654, Stack usage=90 percent. **** BATCH PROCESSING ABORTED **** Is there a way to build boost bypassing this?

4 3

[context] Linux x64 / printf
by Daniel Larimer 12 Sep '12

12 Sep '12

I modified the 'jump.cpp' example and added the line marked CRASH in f1() #include <cstdlib> #include <cstring> #include <iostream> #include <vector> #include <boost/assert.hpp> #include <boost/context/all.hpp> namespace ctx = boost::ctx; ctx::fcontext_t fcm, fc1, fc2; void f1( intptr_t) { std::cout<<"hello "<<0; // WORKS printf( "hello %d", 0 ); // <<< CRASH std::cout << "f1: entered" << std::endl; std::cout << "f1: call jump_fcontext( & fc1, & fc2, 0)" << std::endl; ctx::jump_fcontext( & fc1, & fc2, 0); std::cout << "f1: return" << std::endl; ctx::jump_fcontext( & fc1, & fcm, 0); } void f2( intptr_t) { std::cout << "f2: entered" << std::endl; std::cout << "f2: call jump_fcontext( & fc2, & fc1, 0)" << std::endl; ctx::jump_fcontext( & fc2, & fc1, 0); BOOST_ASSERT( false && ! "f2: never returns"); } int main( int argc, char * argv[]) { ctx::stack_allocator alloc1, alloc2; fc1.fc_stack.base = alloc1.allocate(ctx::minimum_stacksize()); fc1.fc_stack.limit = static_cast< char * >( fc1.fc_stack.base) - ctx::minimum_stacksize(); ctx::make_fcontext( & fc1, f1); fc2.fc_stack.base = alloc2.allocate(ctx::minimum_stacksize()); fc2.fc_stack.limit = static_cast< char * >( fc2.fc_stack.base) - ctx::minimum_stacksize(); ctx::make_fcontext( & fc2, f2); std::cout << "main: call start_fcontext( & fcm, & fc1, 0)" << std::endl; ctx::jump_fcontext( & fcm, & fc1, 0); std::cout << "main: done" << std::endl; return EXIT_SUCCESS; }

4 9

[mpi] scatterv, gatherv and Boost.MPI status
by Alain O Miniussi 11 Sep '12

11 Sep '12

Hi, Despite the fact that https://svn.boost.org/trac/boost/ticket/5292 has been sitting there for some time, the documentations still states that MPI_Allgatherv => most uses supported by all_gather (from 1.51.1). It seems the ticket wasn't commited nor refused. Is there a reason why a c++ MPI_gatherv equivalent is useless in Boost.MPI ? Overall, there seems to be a few other tickets in the same situation in the mpi lib. Which raises another question: what is the exact status of Boost.MPI ? is it still maintained ? is it worth submitting tickets or proposing patches to it or is it safer to move back to the C API ? Best regards Alain

1 0

FW: [Review] Coroutine review starts today, September 3rd, ends September 12th
by Hartmut Kaiser 11 Sep '12

11 Sep '12

This is just a reminder that the review of Oliver's Boost.Coroutine is ending tomorrow (see below for the initial announcement). Please get your reviews in as soon as possible. If you need more time, please let me know. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu > -----Original Message----- > From: Hartmut Kaiser [mailto:hartmut.kaiser@gmail.com] > Sent: Monday, September 03, 2012 6:46 AM > To: boost(a)lists.boost.org > Subject: {Review] Coroutine reviewstarts today, September 3rd > > > Hi all, > > The review of Oliver Kowalke's Boost.Coroutine library starts today, > September 3rd 2012, and will end on September 12th. > I really hope to see your vote and your participation in the discussions > on the Boost mailing lists! > > ----------------------------------------------------- > > About the library: > > Boost.Coroutine provides templates for generalized subroutines > (coroutines) which allow multiple entry points for suspending and resuming > execution at certain locations. It preserves local state/data and allows > re-entering subroutines more than once (useful if state must be kept > across function calls). Coroutines can be viewed as a language-level > construct providing a special kind of control flow. > > You can download the library and the view documentation here: > > docs: http://ok73.ok.funpic.de/boost/libs/coroutine/doc/html/ > src: http://ok73.ok.funpic.de/boost.coroutine.zip > > --------------------------------------------------- > > Please always state in your review, whether you think the library should > be accepted as a Boost library! > > Additionally please consider giving feedback on the following general > topics: > > - What is your evaluation of the design? > - What is your evaluation of the implementation? > - What is your evaluation of the documentation? > - What is your evaluation of the potential usefulness of the library? > - Did you try to use the library? With what compiler? Did you have any > problems? > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? > - Are you knowledgeable about the problem domain? > > Regards Hartmut > Review Manager

1 0

[thread] std::this_thread reference in docs
by Lars Viklund 11 Sep '12

11 Sep '12

Hi list. Since 1.50.0, the Boost.Thread documentation has started making references to std::this_thread::get_id() like in [1]. This is a bit strange, considering that the Thead library itself to my knowledge does not require C++11 (yet). Is this an accidental change? Should one read this as that the error condition is not achievable on C++03? 1.49: Preconditions: this->get_id()!=boost::this_thread::get_id() 1.50 (and 1.51): Preconditions: the thread is joinable. Error Conditions: resource_deadlock_would_occur: if deadlock is detected or this->get_id() == std::this_thread::get_id(). [1] http://www.boost.org/doc/libs/1_51_0/doc/html/thread/thread_management.html… [2] http://www.boost.org/doc/libs/1_49_0/doc/html/thread/thread_management.html… -- Lars Viklund | zao(a)acc.umu.se

2 1

[context] Trying to compile Coroutine on trunk
by Vicente J. Botet Escriba 11 Sep '12

11 Sep '12

Hi, I don't reach to compile Boost.Coroutine under Mac using trunk ../../../boost/coroutine/coroutine.hpp:14:45: error: boost/context/stack_allocator.hpp: No such file or directory ../../../boost/coroutine/coroutine.hpp:15:41: error: boost/context/stack_utils.hpp: No such file or directory Are you changing the interface of Boost.Context? Best, Vicente

4 4