[boost::context] reusing stacks

Hi, I'm working on a tiny coroutine library based on boost::context. For performance reasons I'd rather keep a pool of stacks instead allocating/deallocating every time. Is it legal to reuse a stack for a different context? namespace ctx = boost::context; ctx::fcontext_t fcm, *fc; void f1(intptr_t) { std::cout << "f1" << std::endl; ctx::jump_fcontext(fc, &fcm, 0); } void f2(intptr_t) { std::cout << "f2" << std::endl; ctx::jump_fcontext(fc, &fcm, 0); } int main(int argc, char * argv[]) { ctx::guarded_stack_allocator alloc; std::size_t size = ctx::guarded_stack_allocator::default_stacksize(); void *sp = alloc.allocate(size); fc = ctx::make_fcontext(sp, size, f1); std::cout << "main: jump 1" << std::endl; ctx::jump_fcontext(&fcm, fc, 0); fc = ctx::make_fcontext(sp, size, f2); // legal? std::cout << "main: jump 2" << std::endl; ctx::jump_fcontext(&fcm, fc, 0); std::cout << "main: done" << std::endl; return 0; }

Am 27.11.2012 00:45 schrieb "Valentin Milea" <valentin.milea@gmail.com>:
Hi,
I'm working on a tiny coroutine library based on boost::context. For performance reasons I'd rather keep a pool of stacks instead allocating/deallocating every time. Is it legal to reuse a stack for a different context?
yes, but only one context is allowed to own the stack. If the context is deallocated you could asign the stack to another context via make_fcontext() instead to deallocate it. Therefore your code is not correct (two context's share the same stack at the same time).
int main(int argc, char * argv[]) { ctx::guarded_stack_allocator alloc;
std::size_t size =
ctx::guarded_stack_allocator::default_stacksize();
void *sp = alloc.allocate(size);
fc = ctx::make_fcontext(sp, size, f1); std::cout << "main: jump 1" << std::endl; ctx::jump_fcontext(&fcm, fc, 0);
fc = ctx::make_fcontext(sp, size, f2); // legal? No std::cout << "main: jump 2" << std::endl; ctx::jump_fcontext(&fcm, fc, 0);
std::cout << "main: done" << std::endl;
return 0; }
_______________________________________________ Unsubscribe & other changes:

How do you deallocate a context? With fc being just a struct pointer at beginning of stack, I assumed no special action needed.
yes, but only one context is allowed to own the stack. If the context is deallocated you could asign the stack to another context via make_fcontext() instead to deallocate it.
Therefore your code is not correct (two context's share the same stack at the same time).

== context is not used further make_fcontext() returns a pointer to fcontext_t which is placed at the top of the stack If you call make_fcontext() again with the same stack the content of the previous fcontext_t will be destroyed Am 27.11.2012 08:59 schrieb "Valentin Milea" <valentin.milea@gmail.com>:
How do you deallocate a context? With fc being just a struct pointer at beginning of stack, I assumed no special action needed.
yes, but only one context is allowed to own the stack. If the context is deallocated you could asign the stack to another context via make_fcontext() instead to deallocate it.
Therefore your code is not correct (two context's share the same stack at the same time).
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Just to make sure, this means sample code is actually legal? On Tue, Nov 27, 2012 at 10:09 AM, Oliver Kowalke <oliver.kowalke@gmail.com> wrote:
== context is not used further make_fcontext() returns a pointer to fcontext_t which is placed at the top of the stack If you call make_fcontext() again with the same stack the content of the previous fcontext_t will be destroyed Am 27.11.2012 08:59 schrieb "Valentin Milea" <valentin.milea@gmail.com>:
How do you deallocate a context? With fc being just a struct pointer at beginning of stack, I assumed no special action needed.
yes, but only one context is allowed to own the stack. If the context is deallocated you could asign the stack to another context via make_fcontext() instead to deallocate it.
Therefore your code is not correct (two context's share the same stack at the same time).
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Am 27.11.2012 09:25 schrieb "Valentin Milea" <valentin.milea@gmail.com>:
Just to make sure, this means sample code is actually legal?
yes as long as you do not expect that you can use two or mor context's sharing a stack at the same time. In your example the first context is destroyed by the second call of make_fcontext().
On Tue, Nov 27, 2012 at 10:09 AM, Oliver Kowalke <oliver.kowalke@gmail.com> wrote:
== context is not used further make_fcontext() returns a pointer to fcontext_t which is placed at the top of the stack If you call make_fcontext() again with the same stack the content of the previous fcontext_t will be destroyed Am 27.11.2012 08:59 schrieb "Valentin Milea" <valentin.milea@gmail.com>:
How do you deallocate a context? With fc being just a struct pointer at beginning of stack, I assumed no special action needed.
yes, but only one context is allowed to own the stack. If the context is deallocated you could asign the stack to another context via make_fcontext() instead to deallocate it.
Therefore your code is not correct (two context's share the same stack at the same time).
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/list

yes as long as you do not expect that you can use two or mor context's sharing a stack at the same time. In your example the first context is destroyed by the second call of make_fcontext().
I don't intend to share stacks, just recycle them to avoid allocation overhead. Thanks for help and very useful library!
participants (2)
-
Oliver Kowalke
-
Valentin Milea