[Review.Coroutine] Lifetime of coroutine parameters
Hi, I have some concerns about the lifetime of the coroutine parameters. Surprisingly (well not really), the following example doesn't fails at *1*. This is because the coroutine have access to its coroutine parameters *2*, which has a sens only for the first time the coroutine is called. Once the first call to yield return, the memory these parameter *3* can point to trash, as the example shows. typedef int TT; typedef boost::coro::coroutine< void(TT&) > coro_TT; void lifetime( coro_TT::self_t & self, TT& i ) // *2* { i=1; TT& j = self.yield(); std::cout << i << j << std::endl; i=2; // *3* UNSAFE access to i self.yield(); } void test_lifetime() { coro_TT c( boost::bind( lifetime, _1, _2) ); { int k = 0; c( k ); BOOST_CHECK(k = 1); } { int k = 0; int i = 0; c( i ); BOOST_CHECK(k = 2); // *1* std::cout << i << k << std::endl; } } This could hide errors that are difficult to catch. In addition to merit to be mentioned in the documentation as a limitation of the current library interface I really think that it merits to see if this can be solved. Best, Vicente
Surprisingly (well not really), the following example doesn't fails at *1*. This is because the coroutine have access to its coroutine parameters *2*, which has a sens only for the first time the coroutine is called.
your exchange addresses between main() and coroutine-fn (lifetime()). you could use it also a second time etc. as long as the object does not go out of scope.
Once the first call to yield return, the memory these parameter *3* can point to trash, as the example shows.
sorry - that is not an issue of boost.coroutine itself. Who would store pointers/references to objects and expects that those objects can still be accessed over the pointers/references after those objects were destroyed. But that is the case in your example. Your example in issue *3* is equivalent to storing an reference as member in some class and access the member after the original object was gone out of scope. struct X { void g() {} }; struct Y { X & x; Y( X & x_) : x( x_) {} void f() { x.g(); } }; Y u() { X x; Y y( x); y.f(); // OK } void main() { Y y( u() ); y.f(); // segfault } Oliver
Oliver Kowalke wrote
Surprisingly (well not really), the following example doesn't fails at *1*. This is because the coroutine have access to its coroutine parameters *2*, which has a sens only for the first time the coroutine is called.
your exchange addresses between main() and coroutine-fn (lifetime()). you could use it also a second time etc. as long as the object does not go out of scope.
Once the first call to yield return, the memory these parameter *3* can point to trash, as the example shows.
sorry - that is not an issue of boost.coroutine itself.
Who would store pointers/references to objects and expects that those objects can still be accessed over the pointers/references after those objects were destroyed. But that is the case in your example.
Your example in issue *3* is equivalent to storing an reference as member in some class and access the member after the original object was gone out of scope.
struct X { void g() {} };
struct Y { X & x; Y( X & x_) : x( x_) {} void f() { x.g(); } };
Y u() { X x; Y y( x); y.f(); // OK }
void main() { Y y( u() ); y.f(); // segfault }
Yes, this is similar, except that the current Coroutine interface is giving access to the user to an invalid address to easily. The user has just to use the coroutine parameter. I don't know if you will find a solution, but I expect at least that you will mention it on the documentation with a big warning. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Review-Coroutine-Lifetime-of-coroutine-pa... Sent from the Boost - Dev mailing list archive at Nabble.com.
Yes, this is similar, except that the current Coroutine interface is giving access to the user to an invalid address to easily. The user has just to use the coroutine parameter.
I don't know if you will find a solution, but I expect at least that you will mention it on the documentation with a big warning.
OK Oliver
participants (3)
-
Oliver Kowalke -
Vicente Botet -
Vicente J. Botet Escriba