boostorg / context

boost.context

boost.context is a foundational library that provides a sort of cooperative multitasking on a single thread. By providing an abstraction of the current execution state in the current thread, including the stack (with local variables) and stack pointer, all registers and CPU flags, and the instruction pointer, a execution_context instance represents a specific point in the application's execution path. This is useful for building higher-level abstractions, like coroutines, cooperative threads (userland threads) or an equivalent to C# keyword yield in C++.

A fiber provides the means to suspend the current execution path and to transfer execution control, thereby permitting another fiber to run on the current thread. This state full transfer mechanism enables a fiber to suspend execution from within nested functions and, later, to resume from where it was suspended. While the execution path represented by a fiber only runs on a single thread, it can be migrated to another thread at any given time.

A context switch between threads requires system calls (involving the OS kernel), which can cost more than thousand CPU cycles on x86 CPUs. By contrast, transferring control among fibers requires only fewer than hundred CPU cycles because it does not involve system calls as it is done within a single thread.

boost.context requires C++11!

context's Issues

cmake unable to find boost_context after upgrading from 1.67 to 1.68

So for a while now I use cmake and find_boost to find the headers and libs that I then link to. CMake build worked great no problems. I upgraded to 1.68 and it finds all the other boost libs (system, thread, regex, etc) but boost_context or the context lib.

The library is built and sitting comfortably in stage/lib. I'm using gcc 5.5 and cmake 3.11.4.

Any ideas?

Should I have tried stack overflow first?

Address sanitizer complains when exceptions are thrown

minimal example:

#include <boost/context/all.hpp>

namespace bcx = boost::context;

int main(){
  auto c = bcx::callcc([](bcx::continuation&& c_){
    try {
      throw 5;
    } catch(const int&){
    }
    return std::move(c_);
  });
}

output:

==21820==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffc47270000; bottom 0x631000023000; size: 0x1cec4724d000 (31801131454464)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189

clang v5.0.0 and gcc 7.2.1, boost 1.65.1

Boost v1.67 compile error for MIPS n32 loongson2f CPU

Hello,
I use gentoo on Lemote Yeeloong 8101 notebook which has a MIPS n32 loongson2f CPU. It's OK when I compile without "context" USE flag. Now I want to use KiCad on this computer which need boost recompile with "contest" USE flag:
[ebuild U *] dev-libs/boost-1.67.0:0/1.67.0::gentoo [1.65.0:0/1.65.0::gentoo] USE="context* nls python threads -debug -doc -icu (-mpi) -static-libs -tools" ABI_MIPS="(n32) -n64 -o32" PYTHON_TARGETS="python2_7 python3_6 -python3_4 -python3_5 -python3_7%" 0 KiB
When I compile with "context" USE flag, An error has occurred:

Building the Boost C++ Libraries.


    - symlinks supported       : yes
error: No best alternative for libs/context/build/asm_sources
    next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>elf <threading>multi <toolset>clang
        not matched

warning: Graph library does not contain MPI-based parallel components.
note: to enable them, add "using mpi ;" to your user-config.jam
    - zlib                     : yes
    - bzip2                    : yes
    - lzma                     : yes
    - iconv (libc)             : yes
    - native-atomic-int32-supported : yes
    - native-syslog-supported  : yes
    - pthread-supports-robust-mutexes : yes
    - compiler-supports-visibility : yes
    - x86                      : no
    - arm                      : no
    - mips1                    : no
    - power                    : no
    - sparc                    : no
    - gcc visibility           : yes
    - long double support      : yes
    - libbacktrace builds      : no
    - addr2line builds         : yes
    - WinDbg builds            : no
    - WinDbgCached builds      : no
    - BOOST_COMP_GNUC >= 4.3.0 : yes

 "mips64el-unknown-linux-gnu-g++"   -O2 -march=loongson2f -Wa,-mfix-loongson2f-nop -pipe -std=c++14 -fPIC -pthread -finline-functions -Wno-inline -Wall  -DBOOST_ALL_NO_LIB=1 -DBOOST_CONTEXT_DYN_LINK=1 -DBOOST_FIBERS_DYN_LINK=1 -DBOOST_FIBERS_SOURCE -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DNDEBUG  -I"." -c -o "bin.v2/libs/fiber/build/gcc-8.2/gentoorelease/pch-off/threading-multi/algo/work_stealing.o" "libs/fiber/src/algo/work_stealing.cpp"

{standard input}: Assembler messages:
{standard input}:1475: Error: opcode not supported on this processor: loongson2f (mips3) `pause'
{standard input}:1545: Error: opcode not supported on this processor: loongson2f (mips3) `pause'
{standard input}:1552: Error: opcode not supported on this processor: loongson2f (mips3) `pause'
{standard input}:2254: Error: opcode not supported on this processor: loongson2f (mips3) `pause'
{standard input}:2327: Error: opcode not supported on this processor: loongson2f (mips3) `pause'
...failed updating 1 target...

boost 1.63.0: context_entry() crashes on macOS (tested using boost::fiber)

The following simple test program crashes on macOS (10.12.2; clang-800.0.42.1) with boost 1.63.0:

#include <iostream>
#include <boost/fiber/all.hpp>

int main() {
    std::cout << "main()" << std::endl;
    boost::fibers::fiber f { [] () { std::cout << "fiber test." << std::endl; } };
    f.join();
    std::cout << "main() done." << std::endl;

    return 0;
}
// compile with: clang++ -o main main.cpp --std=c++14 -lboost_fiber-mt -lboost_context-mt 

Debugger output:

% lldb main
(lldb) target create "main"
Current executable set to 'main' (x86_64).
(lldb) run
Process 37616 launched: '/Users/ts/src/fibertest/main' (x86_64)
main()
Process 37616 stopped
* thread #1: tid = 0x327891, 0x00000001000a3bc7 libboost_fiber-mt.dylib`_ZN5boost7context6detail13context_entryINS1_6recordINS0_17execution_contextIJPNS_6fibers6detail6data_tEEEENS0_21basic_fixedsize_stackINS0_12stack_traitsEEEZNS5_7contextC1ENS5_20dispatcher_context_tERKNS0_12preallocatedERKSC_PNS5_9schedulerEE3$_0JEEEEEvNS1_10transfer_tE + 23, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x10)
	frame #0: 0x00000001000a3bc7 libboost_fiber-mt.dylib`_ZN5boost7context6detail13context_entryINS1_6recordINS0_17execution_contextIJPNS_6fibers6detail6data_tEEEENS0_21basic_fixedsize_stackINS0_12stack_traitsEEEZNS5_7contextC1ENS5_20dispatcher_context_tERKNS0_12preallocatedERKSC_PNS5_9schedulerEE3$_0JEEEEEvNS1_10transfer_tE + 23
libboost_fiber-mt.dylib`_ZN5boost7context6detail13context_entryINS1_6recordINS0_17execution_contextIJPNS_6fibers6detail6data_tEEEENS0_21basic_fixedsize_stackINS0_12stack_traitsEEEZNS5_7contextC1ENS5_20dispatcher_context_tERKNS0_12preallocatedERKSC_PNS5_9schedulerEE3$_0JEEEEEvNS1_10transfer_tE:
->  0x1000a3bc7 <+23>: movq   0x10(%r15), %rcx
    0x1000a3bcb <+27>: movq   0x28(%rcx), %rdi
    0x1000a3bcf <+31>: movq   %rax, 0x28(%rcx)
    0x1000a3bd3 <+35>: testq  %rdi, %rdi

The same test program works on linux with boost 1.63.0 and macOS with boost 1.62.0.

I didn't look deeper into it, but based on the debugger output it seems to be rather a problem of boost::context than of boost::fiber, therefore I postet it here.

[libs/context] make_i386_sysv_elf_gas.S:52: Error: invalid instruction suffix for `pop'

I fail to crosscompile the git 1.56 develop while it works on the 1.55 from a windows host targeting linux
Compiling the 64-bit lib also worked, I think it is affecting only the linux target with address-model=32 (a similar issue I got with OSX32_64 and 1.55 that I think you have fixed, but now occurs for me on linux32 and 1.56)

Command used:

b2 -j1 -d2 -q toolset=gcc variant=release abi=sysv address-model=32 binary-format=elf link=static,shared pch=off strip=on target-os=linux threading=multi threadapi=pthread cxxflags="-w -m32" linkflags="-w -m32" --stagedir=stage32 --with-context

1.56 returns (9f37c9b)

Jamfile<X:\libs\boost-dev\libs\context\build>.gas bin.v2\libs\context\build\gcc-4.8.2\release\abi-sysv\address-model-32\architecture-x86\binary-format-elf\link-static\pch-off\strip-on\target-os-linux\threadap
i-pthread\threading-multi\asm\make_i386_sysv_elf_gas.o

    cpp -x assembler-with-cpp "libs\context\src\asm\make_i386_sysv_elf_gas.S" | as -am -o "bin.v2\libs\context\build\gcc-4.8.2\release\abi-sysv\address-model-32\architecture-x86\binary-format-elf\link-static\
pch-off\strip-on\target-os-linux\threadapi-pthread\threading-multi\asm\make_i386_sysv_elf_gas.o"

libs\context\src\asm\make_i386_sysv_elf_gas.S: Assembler messages:
libs\context\src\asm\make_i386_sysv_elf_gas.S:52: Error: invalid instruction suffix for `pop'
libs\context\src\asm\make_i386_sysv_elf_gas.S:64: Error: invalid instruction suffix for `pop'
...failed Jamfile<X:\libs\boost-dev\libs\context\build>.gas bin.v2\libs\context\build\gcc-4.8.2\release\abi-sysv\address-model-32\architecture-x86\binary-format-elf\link-static\pch-off\strip-on\target-os-linu
x\threadapi-pthread\threading-multi\asm\make_i386_sysv_elf_gas.o...
...failed updating 1 target...
...updated 23 targets...

1.55 final returns success

As a workaround I'm changing

    cpp -x assembler-with-cpp "$(>)" | as -am -o "$(<)"

To

    cpp -x assembler-with-cpp "$(>)" | as --32 -am -o "$(<)"

But I'm unsure if that's the right thing to do in my case

C++11? Why?

Boost.Context used to work in C++03 but now claims that C++11 is required. What was the motivation for this change? It breaks Asio without offering an alternative. Can we please remove the C++11 requirement?

Please join the #boost chat at http://cpplang.slack.com

Thank you

std::bind() fails with invoke()

Combined builds for iOS

It is possible to use combined builds on OSX and have a really simple build process but it isn't on iOS where we need to rebuild the library n times and lipo it. It's really inconvenient!
So, what do you think about having a similar file for iOS and use the preprocessor to automatically use the right implementation for the processor?

Also, out of curiosity, why don't you maintain such a file to handle the tier1 platforms and compilers and automatically pick the right implementation?

Unknown directive .cpu on aarch64 with Clang 3.8 on Android

The aarch64 files don't compile on Android with the Clang compiler because of the .cpu directive that is unsupported in version 3.8.
Support has been added to 3.9 r265240 but that version of the compiler hasn't been released with any NDK yet.

Could the offending lines be removed from all 3 arm64 elf files?
Note there's no regression test runs for aarch64 + clang in the test suite, that would explain why no one noticed before.

Crash when allocating control structures on top of stack with ec v2

I wanted to allocate the control structures on top of stack as demonstrated in the tutorial, but I couldn't find any complete example or test for that feature.

I wrote this, which is mostly a copy paste from the tutorial:

#include <boost/context/execution_context_v2.hpp>

using namespace boost::context;

struct my_control_structure
{
  // captured context
  execution_context<void> cctx;

  template <typename StackAllocator>
  my_control_structure(void* sp,
                       std::size_t size,
                       stack_context sctx,
                       StackAllocator salloc)
    : // create captured context
      cctx(std::allocator_arg, preallocated(sp, size, sctx), salloc, [](auto ctx){return ctx;})
  {
  }
};

int main(int argc, char* argv[])
{
  // stack-allocator used for (de-)allocating stack
  fixedsize_stack salloc(8192);
  // allocate stack space
  stack_context sctx(salloc.allocate());
  // reserve space for control structure on top of the stack
  void* sp = static_cast<char*>(sctx.sp) - sizeof(my_control_structure);
  std::size_t size = sctx.size - sizeof(my_control_structure);
  // placement new creates control structure on reserved space
  my_control_structure* cs =
      new (sp) my_control_structure(sp, size, sctx, salloc);

  cs->cctx();

  // destructing the control structure
  // CRASH, the stack has already been freed
  cs->~my_control_structure();

  return 0;
}

But this program crashes when compiled with ASan, because the stack is freed when the coroutine returns, so we can't call the destructor of my_control_structure, the pointer is already invalid.

We can't call it just before the return statement either since the coroutine is still running, and not calling it at all would leak memory.

ump_arm_aapcs_macho_gas.S doesn't compile

An attempt to compile using clang produces:

libs/context/src/asm/jump_arm_aapcs_macho_gas.S:94:11: error: invalid operand for instruction
pop v1
^

The fix is straightforward:

put {v1}

"rename of continuation member functions" missed a spot

We (the MSVC++ team) do a nightly build of the latest boost sources as a compiler "Real World Code" test. We noticed a build break after the "rename of continuation member functions" change in test/test_callcc.cpp. Line 281 still has a c(), this should probably be changed to c.resume().

Failing to build callcc test with g++-4.9

The callcc test fails to build when using version 4.9 of the GCC toolchain. The compiler gives an error about ambiguous overloads of the callcc function, which I think is a known bug in gcc-4.9 that was fixed in gcc-5.

I got the same error on Linux for in both PowerPC (32-bit) and x86_64 builds. Unfortunately, gcc-4.9 was the newest compiler I was able to get installed on the 32-bit PowerPC system for testing, so without support for that toolchain I can't test the ppc/sysv/elf platform (see #50).

I tried adding an extra disable_overload to disambiguate the call, which allowed me to compile, but then the test failed due to bad values being passed through the continuation object... I will try to look at this again later, but you're obviously more familiar with the codebase, and I'm hoping if you can get g++-4.9 installed that you'll have a much easier time debugging this.

Why was fcontext moved into detail::/deprecated? Can it be public again?

Can fcontext please be made part of the public API (and stabilized)?

The new execution_context removes too much freedom for me. Primarily, I don't want uncaught exceptions to be caught and rethrown in the parent coroutine, as this messes up stack traces from backward-cpp.

fcontext alone provided a great, clean, portable replacement for the deprecated POSIX ucontext functions.

Bad assembly for fcontext on ppc64/sysv/elf

This past week I was testing some code (which uses Boost.Context routines) on a POWER7 RHEL system. I had hundreds of successful test runs on x86_64 machines, but I was getting segfaults everywhere on the ppc64 system. I traced the problems back to the machine code for the fcontext functions, where I identified several bugs in the assembly routines:

1. Saving r29 into r28's spot (typo).
2. Assuming identical ABI for returning transfer_t struct and passing the struct as the first argument to a function.
3. No distinction between ELF v1 and v2 in the ontop_fcontext when jumping into the target function.

These bugs were introduced in v1.61, which is when the internal fcontext interface was updated. I didn't have any problems previously when using v1.54. I've patched the ppc64_sysv_elf_gas versions of the fcontext functions, and I'll open a pull request shortly; however, the same bugs are also present in the code for other ppc targets.

I was surprised to find so many bugs in the code. When I ran the unit tests on the POWER7 machine, they failed consistently. This leads me to think this code was not actually tested. I understand that the library maintainers might not have the resources to test the code on all of the "supported" platforms; however, maintaining some sort of a testing matrix in the documentation listing which versions have been verified would be useful. Adding an obvious warning to check the verification status for platforms with lower-priority support would also be helpful.

`__sanitizer_finish_switch_fiber` should be called directly after context switch

According to the AddressSanitizer API:

When code starts running on the new stack, it must call __sanitizer_finish_switch_fiber to finalize the switch.

Currently, Boost.Context calls __sanitizer_finish_switch_fiber directly before the context switch (instead of direc;tly after):

context/include/boost/context/continuation_ucontext.hpp

Line 144 in 82bf54e

__sanitizer_finish_switch_fiber( from->fake_stack, (const void **) & from->stack_bottom,

This basically leads to ASan permanently being in "switching stacks" mode. Consequently, the test program from boostorg/coroutine#30 (comment) crashes with an AddressSanitizer error even when using Boost.Coroutine2.

x64-Win32 SetUnhandledExceptionFilter does not work with make_fcontext/jump_fcontext

On win32-x64, calling a function through jump_fcontext, our handler registered through SetUnhandledExceptionFilter is not called.

I've made a project illustrating the problem:
https://github.com/jonasmr/boost_context_seh

Note, that it has to be launched without attaching the debugger, as the exception handler is never called when the debugger attached.

Note that the application crashes, instead of printing "ExceptionHandler" to the console.

Its using (jump/make)_x86_64ms_pe_masm.

make_fcontext is non-portable.

The example given in the Boost documentation gives make_fcontext as taking a block of heap memory for the new stack. In the example, pointer from malloc is given directly to make_fcontext. However, the behaviour of make_fcontext is architecture dependent. It either expects a pointer to the bottom of the stack (consistent with the result of malloc) or the top of the stack (which requires pointer arithmetic to derive the end of the malloc block)

Code that uses this interface is therefore non-portable. Since the size of the stack is always passed to make_fcontext it would be trivial to update the assembler implementation to ALWAYS expect a pointer to the bottom of the stack, making interfacing code portable again.

Can thread specific storage be used together with boost context?

I am testing on OSX using the simplified code below. From the main thread:

    int rc = pthread_key_create(&tlsKey, nullptr);
    assert(!rc);

From another thread:

    int rc = pthread_setspecific(tlsKey, (void*)0x12345678);
    assert(!rc);
    assert((void*)0x12345678 == pthread_getspecific(tlsKey)); // OK

    // code that switches contexts using jump_fcontext back and forth
    ...

    assert((void*)0x12345678 == pthread_getspecific(tlsKey);  // FAILURE, returns NULL

Arguments forwarding

Why calcc() and continuation::resume() pass arguments by value (Arg ...) instead of forwarding references (Arg && ...)?

jump_fcontext crashes in 32bit iOS simulator

jump_fcontext crashes in jump_i386_sysv_macho_gas.S when trying mov the "to" fctx parameter into eax. This is easy to reproduce on a mac by compiling a simple program with the assembly files and a simple main function. (This example works with the old assembly files before the refactoring to have transfer_t etc)

With a little debugging it seems like the offsets to get the "to" and "data" parameters are not correct anymore. The seem to be off by 4 bytes.

Compile with: g++ -g *.S main.cc -m32 -std=c++11

#include
#include

typedef void* fcontext_t;

struct transfer_t {
fcontext_t fctx;
void* data;
};

extern "C"
transfer_t jump_fcontext(fcontext_t const to, void* vp);
extern "C"
fcontext_t make_fcontext(void* stack_pointer, size_t size,
void (*fn)(transfer_t));

void Run(transfer_t t) {
printf("not reached");
}

int main() {
const size_t size = 131072;
char* smem = (char*)malloc(size);
void* sp = smem + size;

fcontext_t fctx = make_fcontext(sp, size, &Run);
// jump_fcontext crashes.
jump_fcontext(fctx, nullptr);
}

Linker error with `context-impl=ucontext`: multiple definition of `boost::context::detail::current_rec`

When building with context-impl=ucontext define=BOOST_USE_UCONTEXT on branch develop (commit 7900c86) I get the following linker error:

bin.v2/libs/context/build/gcc-7.3.0/release/context-impl-ucontext/threading-multi/fiber.o:(.tbss+0x18): multiple definition of `boost::context::detail::current_rec'
bin.v2/libs/context/build/gcc-7.3.0/release/context-impl-ucontext/threading-multi/continuation.o:(.tbss+0x18): first defined here
collect2: error: ld returned 1 exit status

    "g++"    -o "bin.v2/libs/context/build/gcc-7.3.0/release/context-impl-ucontext/threading-multi/libboost_context.so.1.67.0" -Wl,-h -Wl,libboost_context.so.1.67.0 -shared -Wl,--start-group "bin.v2/libs/context/build/gcc-7.3.0/release/context-impl-ucontext/threading-multi/continuation.o" "bin.v2/libs/context/build/gcc-7.3.0/release/context-impl-ucontext/threading-multi/fiber.o" "bin.v2/libs/context/build/gcc-7.3.0/release/context-impl-ucontext/threading-multi/execution_context.o" "bin.v2/libs/context/build/gcc-7.3.0/release/context-impl-ucontext/threading-multi/posix/stack_traits.o"  -Wl,-Bstatic  -Wl,-Bdynamic -lrt -Wl,--end-group -fPIC -m64 -pthread 

The multiple definitions are here:

fiber.cpp:24: thread_local fiber_activation_record * current_rec;
continuation.cpp:26: thread_local activation_record * current_rec;

Some troubles trying to contruct an execution_context (v2) while sitting on the stack of another one

Hello,

I use boost_context for a toy project of coroutine scheduler to be found here:
https://github.com/matovitch/coscheV3.

It works as expected as long as don't try to nest my coroutine. You can see an example here:
https://github.com/matovitch/coscheV3/blob/master/examples/nested.cpp.

The example appears to be working fine, but valgrind complains of invalid reads in the context contructor:

==21651== Use of uninitialised value of size 8
==21651==    at 0x40CBB7: jump_fcontext (jump_x86_64_sysv_elf_gas.S:64)
==21651==    by 0x40DD3D: boost::context::v2::execution_context<cosche::task::Abstract*>::execution_context<boost::context::v2::execution_context<cosche::task::Abstract*> (&)(boost::context::v2::execution_context<cosche::task::Abstract*>&&, cosche::task::Abstract*), , void>(boost::context::v2::execution_context<cosche::task::Abstract*> (&)(boost::context::v2::execution_context<cosche::task::Abstract*>&&, cosche::task::Abstract*)) (execution_context_v2.hpp:167)
==21651==    by 0x40DCA4: cosche::task::Abstract::Abstract(cosche::scheduler::Abstract&) (task.cpp:26)
==21651==    by 0x4092F6: cosche::TTask<void>::TTask(cosche::scheduler::Abstract&) (in /home/cbrugel/workspace/C++/coscheV3/build/examples/nested)
==21651==    by 0x40727C: cosche::TTask<void>& cosche::pool::TFactory<cosche::TTask<void>, 4096ul>::make<cosche::TScheduler<4096ul, 4096ul, 4096ul>&>(cosche::TScheduler<4096ul, 4096ul, 4096ul>&) (pool_factory.hpp:31)
==21651==    by 0x401D84: cosche::TNode<cosche::task::Abstract*>& cosche::TScheduler<4096ul, 4096ul, 4096ul>::makeTask<void>() (scheduler.hpp:45)
==21651==    by 0x401C17: main::$_0::operator()() const (nested.cpp:23)
==21651==    by 0x401ACC: std::_Function_handler<void (), main::$_0>::_M_invoke(std::_Any_data const&) (std_function.h:316)
==21651==    by 0x40982D: std::function<void ()>::operator()() const (in /home/cbrugel/workspace/C++/coscheV3/build/examples/nested)
==21651==    by 0x40AA6C: void std::__invoke_impl<void, std::function<void ()>&>(std::__invoke_other, std::function<void ()>&) (in /home/cbrugel/workspace/C++/coscheV3/build/examples/nested)
==21651==    by 0x40AA3C: std::__invoke_result<std::function<void ()>&>::type std::__invoke<std::function<void ()>&>(std::function<void ()>&) (in /home/cbrugel/workspace/C++/coscheV3/build/examples/nested)
==21651==    by 0x40AA08: void std::_Bind<std::function<void ()> ()>::__call<void>(std::tuple<>&&, std::_Index_tuple<>) (in /home/cbrugel/workspace/C++/coscheV3/build/examples/nested)

Here is a minimal example producing the same result.

#include <iostream>

#include "cosche/scheduler.hpp"
#include "cosche/utils.hpp"

static constexpr std::size_t ABSTRACT_TASK_ALLOCATOR_BUFFER_SIZE = 4096;
static constexpr std::size_t CONCRETE_TASK_ALLOCATOR_BUFFER_SIZE = 4096;
static constexpr std::size_t        FUTURE_ALLOCATOR_BUFFER_SIZE = 4096;

using Scheduler = cosche::TScheduler<ABSTRACT_TASK_ALLOCATOR_BUFFER_SIZE, 
                                     CONCRETE_TASK_ALLOCATOR_BUFFER_SIZE, 
                                            FUTURE_ALLOCATOR_BUFFER_SIZE>;

int main()
{
    Scheduler scheduler;

    auto&& rootTask = scheduler.makeTask<void>();

    std::function<void()> rootWork = 
        [&]()
        {
            auto&& leafTask = scheduler.makeTask<void>();
        };

    cosche::assignWork(rootTask, std::move(rootWork));

    scheduler.run();

    cosche::cleanUp();

    return 0;
}

We could dismiss it as a false positive. But it doesn't seem to be because after nesting only 6 times with a binary-tree-like task graph, it cores. I believed to have an explanation but I had read the documentation incorrectly. Still not sure about these invalid reads. Can you help me on this ? Do you understand what happen there ?

Thanks a lot for your help and for taking the time to read this.

Appveyor errors

I get this error with the latest Boost.Context now:

C:\projects\boost-root\boost/context/execution_context_v1.hpp(60): error C2492: 'boost::context::detail::ecv1_activation_record::current_rec': data with thread storage duration may not have dll interface
C:\projects\boost-root\boost/context/execution_context_v1.hpp(60): warning C4251: 'boost::context::detail::ecv1_activation_record::current_rec': class 'boost::intrusive_ptr<boost::context::detail::ecv1_activation_record>' needs to have dll-interface to be used by clients of struct 'boost::context::detail::ecv1_activation_record'
C:\projects\boost-root\boost/context/execution_context_v1.hpp(58): note: see declaration of 'boost::intrusive_ptr<boost::context::detail::ecv1_activation_record>'
C:\projects\boost-root\boost/context/execution_context_v1.hpp(60): error C2492: 'public: static boost::intrusive_ptr<boost::context::detail::ecv1_activation_record> boost::context::detail::ecv1_activation_record::current_rec': data with thread storage duration may not have dll interface

boost 1.63: jump_x86_64_ms_pe_gas.asm, ontop_x86_64_ms_pe_gas.asm

I use MinGW-w64 (b2 toolset=gcc on Windows)

Program received signal SIGSEGV, Segmentation fault.
jump_fcontext () at jump_x86_64_ms_pe_gas.asm:191
191         movq  %r9, (%rax)

The line in jump_x86_64_ms_pe_gas.asm

movq  0x110(%rsp), %rcx  /* restore hidden address of transport_t */

differs from the corresponding one in jump_x86_64_ms_pe_masm.asm which contains

mov rax, [rsp+0110h] ; restore hidden address of transport_t

Cross compile boost_context for arm: undefined reference to jump_fcontext/make_fcontext

Created my user-config.jam as per: http://www.boost.org/build/doc/html/bbv2/tasks/crosscompile.html

My user-config.jam:
using gcc : arm : arm-linux-gnueabihf-g++ ;

Building with b2 toolset=gcc-arm gives me:

error: No best alternative for libs/context/build/asm_sources
    next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>elf <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>elf <threading>multi <toolset>gcc
        not matched
    next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>elf <threading>multi <toolset>qcc
        not matched
    next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>mach-o <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>mach-o <threading>multi <toolset>darwin
        not matched
    next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>pe <threading>multi <toolset>msvc
        not matched
    next alternative: required properties: <abi>aapcs <address-model>64 <architecture>arm <binary-format>elf <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>aapcs <address-model>64 <architecture>arm <binary-format>elf <threading>multi <toolset>gcc
        not matched
    next alternative: required properties: <abi>aapcs <address-model>64 <architecture>arm <binary-format>mach-o <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>aapcs <address-model>64 <architecture>arm <binary-format>mach-o <threading>multi <toolset>darwin
        not matched
    next alternative: required properties: <abi>o32 <address-model>32 <architecture>mips1 <binary-format>elf <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>o32 <address-model>32 <architecture>mips1 <binary-format>elf <threading>multi <toolset>gcc
        not matched
    next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>elf <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>elf <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>mach-o <threading>multi <toolset>darwin
        not matched
    next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>xcoff <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>xcoff <threading>multi <toolset>gcc
        not matched
    next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>elf <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>elf <threading>multi <toolset>gcc
        not matched
    next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>mach-o <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>mach-o <threading>multi <toolset>darwin
        not matched
    next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>xcoff <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>xcoff <threading>multi <toolset>gcc
        not matched
    next alternative: required properties: <abi>sysv <address-model>32_64 <architecture>power <binary-format>mach-o <threading>multi
        not matched
    next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf <threading>multi <toolset>gcc
        not matched
    next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf <threading>multi <toolset>intel
        not matched
    next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>darwin
        not matched
    next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>clang-win
        not matched
    next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>gcc
        not matched
    next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>intel
        not matched
    next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>msvc
        not matched
    next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>gcc
        not matched
    next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>intel
        not matched
    next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>darwin
        not matched
    next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>intel
        not matched
    next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>clang-win
        not matched
    next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>gcc
        not matched
    next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>intel
        not matched
    next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>msvc
        not matched
    next alternative: required properties: <abi>x32 <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>x32 <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>gcc
        not matched
    next alternative: required properties: <abi>x32 <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>intel
        not matched
    next alternative: required properties: <abi>sysv <address-model>32_64 <architecture>x86 <binary-format>mach-o <threading>multi
        not matched
    next alternative: required properties: <abi>sysv <architecture>combined <binary-format>mach-o <threading>multi
        not matched

Any ideas on how to get this working?

can boost.context worked with C++0x

Hi
I am trying to use boost.context in our project (may warp out a simple coroutine interface).
Because all our product environment is base on CentOS 6.x, the default gcc version is 4.4.7, only support C++0x.

I am wondering:

1. Can the latest stable boost.context work with C++0x? or what's the last support version can fit with C++0x requirements.
2. What's the ec_v1 and ec_v2 relations with C++11? I can some CXX11 macro protect them.

Thanks and wait for your reply.

Clang on Windows : error: No best alternative for libs/context/build/asm_sources

compiling with Clang on Windows triggers the following errors:

error: No best alternative for libs/context/build/asm_sources
    next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>elf <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>elf <threading>multi <toolset>gcc
        not matched
    next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>elf <threading>multi <toolset>qcc
        not matched
    next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>mach-o <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>mach-o <threading>multi <toolset>darwin
        not matched
    next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>pe <threading>multi <toolset>msvc
        not matched
    next alternative: required properties: <abi>aapcs <address-model>64 <architecture>arm <binary-format>elf <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>aapcs <address-model>64 <architecture>arm <binary-format>elf <threading>multi <toolset>gcc
        not matched
    next alternative: required properties: <abi>aapcs <address-model>64 <architecture>arm <binary-format>mach-o <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>aapcs <address-model>64 <architecture>arm <binary-format>mach-o <threading>multi <toolset>darwin
        not matched
    next alternative: required properties: <abi>o32 <address-model>32 <architecture>mips1 <binary-format>elf <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>o32 <address-model>32 <architecture>mips1 <binary-format>elf <threading>multi <toolset>gcc
        not matched
    next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>elf <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>elf <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>mach-o <threading>multi <toolset>darwin
        not matched
    next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>xcoff <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>xcoff <threading>multi <toolset>gcc
        not matched
    next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>elf <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>elf <threading>multi <toolset>gcc
        not matched
    next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>mach-o <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>mach-o <threading>multi <toolset>darwin
        not matched
    next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>xcoff <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>xcoff <threading>multi <toolset>gcc
        not matched
    next alternative: required properties: <abi>sysv <address-model>32_64 <architecture>power <binary-format>mach-o <threading>multi
        not matched
    next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf <threading>multi <toolset>gcc
        not matched
    next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf <threading>multi <toolset>intel
        not matched
    next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>darwin
        not matched
    next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>clang-win
        not matched
    next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>gcc
        not matched
    next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>intel
        not matched
    next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>msvc
        not matched
    next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>gcc
        not matched
    next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>intel
        not matched
    next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>darwin
        not matched
    next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>intel
        not matched
    next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>clang-win
        not matched
    next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>gcc
        not matched
    next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>intel
        not matched
    next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>msvc
        not matched
    next alternative: required properties: <abi>x32 <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>clang
        not matched
    next alternative: required properties: <abi>x32 <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>gcc
        not matched
    next alternative: required properties: <abi>x32 <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>intel
        not matched
    next alternative: required properties: <abi>sysv <address-model>32_64 <architecture>x86 <binary-format>mach-o <threading>multi
        not matched
    next alternative: required properties: <abi>sysv <architecture>combined <binary-format>mach-o <threading>multi
        not matched

my user-config.jam:

using clang : 5.0 :
 "C:/Program Files/LLVM/bin/clang.exe" :
 <compileflags>-fmsc-version=1910
 <compileflags>-DBOOST_USE_WINAPI_VERSION=0x0502
 <compileflags>-DBOOST_USE_WINDOWS_H=1
 <compileflags>-D_WIN32_WINNT=0x0502
 <compileflags>-DNOMINMAX
 <cxxflags>"-I\"C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.11.25503\\ATLMFC\\include\""
 <cxxflags>"-I\"C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.11.25503\\include\""
 <cxxflags>"-I\"C:\\Program Files (x86)\\Windows Kits\\NETFXSDK\\4.6.1\\include\\um\""
 <cxxflags>"-I\"C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.15063.0\\ucrt\""
 <cxxflags>"-I\"C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.15063.0\\shared\""
 <cxxflags>"-I\"C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.15063.0\\um\""
 <cxxflags>"-I\"C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.15063.0\\winrt\""
 <ranlib>"C:/Program Files/LLVM/bin/llvm-ranlib.exe" 
 <archiver>"C:/Program Files/LLVM/bin/llvm-ar.exe" 
 <linkflags>-fuse-ld=lld ;

Missing symbols when build with vcpkg

The libboost_context.a missing symbols:
make_fcontext
jump_fcontext
ontop_fcontext

when boost.context built by vcpkg.
I think your build script what you committed, lose the asm files in vcpkg.

have a plan to support riscv platform?

riscv is very popular, have a plan to support riscv platform?

Update documentation concerning private fcontext APIs

Although fcontext was removed from the public APIs in boost 1.61.0, it's still documented as public here:
https://github.com/boostorg/context/blob/develop/README.md
http://www.boost.org/doc/libs/1_61_0/libs/context/doc/html/context/context.html

Please add support for Cygwin platform

Let's apply a couple of lines:

$ git diff build/Jamfile.v2
diff --git a/build/Jamfile.v2 b/build/Jamfile.v2
index af8de28..855fd35 100644
--- a/build/Jamfile.v2
+++ b/build/Jamfile.v2
@@ -47,6 +47,7 @@ local rule default_binary_format ( )
     local tmp = elf ;
     if [ os.name ] = "MACOSX" { tmp = mach-o ; }
     if [ os.name ] = "NT" { tmp = pe ; }
+    if [ os.name ] = "CYGWIN" { tmp = pe ; }
     if [ os.name ] = "AIX" { tmp = xcoff ; }
     return $(tmp) ;
 }
@@ -65,6 +66,7 @@ local rule default_abi ( )
 {
     local tmp = sysv ;
     if [ os.name ] = "NT" { tmp = ms ; }
+    if [ os.name ] = "CYGWIN" { tmp = ms ; }
     else if [ os.platform ] = "ARM" { tmp = aapcs ; }
     else if [ os.platform ] = "MIPS" { tmp = o32 ; }
     return $(tmp) ;

Create continuation without resuming

How to create new continuation but don't switch the context? callcc() always calls resume(). With old execution_context we could just use the constructor. Why such constructor was removed?
It is useful when one creates a number of coroutines then starts all of them after successful creation.

Possible resource leak in ucontext implementation

Hi,

I see some strange pattern in continuation_ucontext.hpp:

Line 295: we construct new object using placement new operator https://github.com/boostorg/context/blob/develop/include/boost/context/continuation_ucontext.hpp#L295
Line 302: we throw exception https://github.com/boostorg/context/blob/develop/include/boost/context/continuation_ucontext.hpp#L302

Same pattern we can find in function create_context2

Do we need to destroy our object before throwing exception?

Comparisons with execution_contexts.

execution_context is a very low-level, low-overhead tool. As it should be; it needs to be a foundation for others to build on top of. However, it does lack a few features that make working with it more difficult than strictly necessary.

For example, imagine a scheduler where users can pass it an execution_context. This scheduler will execute these contexts (within the confines of a single thread, perhaps). The purpose of the system is to allow each coroutine to decide when it is OK to task-switch to another task in the scheduler. So you effectively yield to the scheduler, who picks the next task to execute (note that "yield" does not necessarily mean switching to the scheduler's context, as that would be a waste of a context switch).

That is all implementable as Boost.Context currently exists. The problem is how to prevent mistakes.

If a user hands an execution_context off to the scheduler to manage, how do you prevent the user from accidentally adding the same context twice? The traditional way would be with set (or more reasonably flat_set). But without operator<, and without anything that could be used to create such an comparison operation (comparing the internal data, not the wrapper), such containers cannot be used.

Also, with such a system, it is difficult to remove a context from its care. It is not impossible of course; one can use a helper object system like Boost.Signal2 does to unregister listeners. But it would be easier for users if they could just say unregister(ec).

There are other situations where these operations would be useful. For example, users might want to associate arbitrary user data with an execution context. This would allow them to get execution_context::current() and use that to fetch that context's additional data (let's ignore the fact that this would keep the context alive longer than is strictly necessary, since intrusive_ptr's don't have weak references. That's a possible feature for another day).

The common way to do this would be with a map of some kind, between execution_context as the key and the associated data values. std::map needs operator< or some other form of comparability between key types. std::unordered_map needs both operator== and hashing support.

What's worse is that there is no way to synthesize such operations (at least, not without trickery/UB). execution_context is a fully opaque wrapper around a smart pointer, with no way to tell anything about the internal data except whether it actually wraps some internal data.

Given the current implementation of Boost.Context as a wrapper around a reference-counted pointer to a type, it should be trivial to implement operator==, operator<, and hashing support. These features would have no impact on the performance of the type, and they would non-trivially improve its usability.

Build reproducibility: Add .file section for *_elf_gas.S files

Add a .file directive to all *_elf_gas.S files to prevent the linker adding a host build-system path as a FILE symbol to the object file. Without this, the gnu linker adds a symbol like this:

0000000000000000 0 FILE LOCAL DEFAULT ABS /path/to/my/build/.../asm/make_x86_64_sysv_elf_gas.o

The attached file is a .patch file, but GitHub wouldn't upload it with the .patch extension:
0001-Reproducibility-Add-file-section-for-elf-gas-S-files.patch.txt

fibonacci example throws forced_unwind on mingw

on mingw (crosscompiling from Fedora 29, gcc 8.3.0, both x86_64 and i686 targets) the fibonacci example throws

0 1 1 2 3 5 8 13 21 34 
main: done
terminate called after throwing an instance of 'boost::context::detail::forced_unwind'

To reproduce:

FROM fedora:29
RUN dnf install -y mingw64-boost wine-devel
WORKDIR /tmp
RUN curl -fsSLO https://raw.githubusercontent.com/boostorg/context/develop/example/execution_context_v2/fibonacci.cpp
RUN x86_64-w64-mingw32-g++ fibonacci.cpp -lboost_context-mt
RUN WINEPATH=/usr/x86_64-w64-mingw32/sys-root/mingw/bin/ WINEARCH=win64 wine ./a.exe

Here Fedora uses boost 1.66 but I checked the same problem occurs with 1.69 on another box

Removal of all.hpp breaks CMake

While this is not strictly a Boost issue, but this commit 2e37599 breaks FindBoost.cmake, because this script uses context/all.hpp to detect the presence of Boost.Context headers (if missing, it concludes Boost.Context is not present in the system).

Example:

find_package(Boost 1.67
             COMPONENTS
                fiber
                context
             REQUIRED)

Relevant FindBoost.cmake line:
https://github.com/Kitware/CMake/blob/v3.11.0/Modules/FindBoost.cmake#L875

undefined reference to `make_fcontext' on mingw

on mingw (Fedora 29, gcc 8.3.0) boost.context builds successfuly, but has undefined symbols, here on the fibonnacci example

$ x86_64-w64-mingw32-g++ fibonacci.cpp -lboost_context-mt
... undefined reference to `make_fcontext'
... undefined reference to `jump_fcontext'
... undefined reference to `jump_fcontext'
... undefined reference to `ontop_fcontext'
...
collect2: error: ld returned 1 exit status

But, if built with the fedora patch, all symbols are resolved and the build suceeds (but returns an exception, see #100):

--- libs/context/build/Jamfile.v2.orig	2013-03-03 13:39:59.684868916 +0100
+++ libs/context/build/Jamfile.v2	2013-03-03 15:09:09.893232829 +0100
@@ -47,10 +47,11 @@
 local rule default_binary_format ( )
 {
     local tmp = elf ;
-    if [ os.name ] = "NT" { tmp = pe ; }
-    else if [ os.name ] = "CYGWIN" { tmp = pe ; }
-    else if [ os.name ] = "AIX" { tmp = xcoff ; }
-    else if [ os.name ] = "MACOSX" { tmp = mach-o ; }
+    #if [ os.name ] = "NT" { tmp = pe ; }
+    #else if [ os.name ] = "CYGWIN" { tmp = pe ; }
+    #else if [ os.name ] = "AIX" { tmp = xcoff ; }
+    #else if [ os.name ] = "MACOSX" { tmp = mach-o ; }
+    tmp = pe ;
     return $(tmp) ;
 }
 
@@ -67,10 +68,11 @@
 local rule default_abi ( )
 {
     local tmp = sysv ;
-    if [ os.name ] = "NT" { tmp = ms ; }
-    else if [ os.name ] = "CYGWIN" { tmp = ms ; }
-    else if [ os.platform ] = "ARM" { tmp = aapcs ; }
-    else if [ os.platform ] = "MIPS" { tmp = o32 ; }
+    #if [ os.name ] = "NT" { tmp = ms ; }
+    #else if [ os.name ] = "CYGWIN" { tmp = ms ; }
+    #else if [ os.platform ] = "ARM" { tmp = aapcs ; }
+    #else if [ os.platform ] = "MIPS" { tmp = o32 ; }
+    tmp = ms ;
     return $(tmp) ;
 }

I guess boost.context doesnt know how to detect this format/abi when compiling from Linux with a gcc compiler for the windows target (pe binary format, ms abi), is this a known issue ?

Link to the fedora rpm (for 1.66 but their patch is still a valid workaround for 1.69, did they report that bug to you ?):
https://www.rpmfind.net/linux/RPM/fedora/devel/rawhide/ppc64le/m/mingw64-boost-1.66.0-3.fc30.noarch.html

The requirements documentation page should include minimum compler compatability

We need to include minimum compiler versions (and switches?) supported for this library on the "requirements" page of the documentation. It is noted that a C++11 compiler is required, but msvc-12.0 (Visual Studio 2013) doesn't work....even though microsoft proudly trumpeted it as C++11 compliant (with a couple minor provisos). GCC/Clang version required would also be nice.

NEON registers

Currently, jump_fcontext on ARM 32 doesn't either save or restore VFP registers (used by NEON).
It can lead to serious problems, for example, when compiler uses VFP registers during optimization.

Is it done by intention?

undefined mingw64 symbols {make,jump}_fcontext when linking coroutine

hi,

i'm trying to build boost 1.58 for mingw64 and it fails for at least the i386 target:

toolset=gcc-mingw64 \
      target-os=windows \
      variant=release \
      threading=multi \
      threadapi=win32 \
      link=shared,static \
      runtime-link=shared \
      --prefix=${pkgdir}/usr/i686-w64-mingw32 \
      --user-config=user-config.jam \
      --without-mpi \
      --without-graph_parallel \
      --without-python \
      cxxflags="-std=c++11 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4" \
      address-model=i686-w64-mingw32 \
      architecture=x86 \
      binary-format=pe \

and using this patch:
http://pkgs.fedoraproject.org/cgit/mingw-boost.git/tree/boost-mingw.patch

i've got the following error:

gcc.link.dll bin.v2/libs/coroutine/build/gcc-mingw-mingw64/release/binary-format-pe/target-os-windows/threadapi-win32/threading-multi/libboost_coroutine-mt.dll.a
bin.v2/libs/coroutine/build/gcc-mingw-mingw64/release/binary-format-pe/target-os-windows/threadapi-win32/threading-multi/detail/coroutine_context.o:coroutine_context.cpp:(.text+0x4a): undefined reference to `_imp__make_fcontext'
bin.v2/libs/coroutine/build/gcc-mingw-mingw64/release/binary-format-pe/target-os-windows/threadapi-win32/threading-multi/detail/coroutine_context.o:coroutine_context.cpp:(.text+0xc7): undefined reference to `_imp__jump_fcontext'

however it's very similar to what was fixed here:
70fab42

boost 1.64.0: Boost.Context fails to build -> Call of overloaded 'callcc(...) is ambiguous'

I was trying to compile Boost 1.64.0 for OpenWRT when the build failed for Arm Cortex A7 (Raspberry Pi 2) using Gcc 5.2 with Musl 1.1.16.

The build output with the error follows.

Any ideas on what it could be ?

gcc.compile.c++ bin.v2/libs/fiber/build/gcc-arm/release/abi-aapcs/boost.locale.iconv-on/boost.locale.posix-off/link-static/threading-multi/context.o
libs/fiber/src/context.cpp: In constructor 'boost::fibers::context::context(boost::fibers::dispatcher_context_t, const boost::context::preallocated&, const default_stack&, boost::fibers::scheduler*)':
libs/fiber/src/context.cpp:236:14: error: call of overloaded 'callcc(const std::allocator_arg_t&, const boost::context::preallocated&, const default_stack&, boost::fibers::context::context(boost::fibers::dispatcher_context_t, const boost::context::preallocated&, const default_stack&, boost::fibers::scheduler*)::<lambda(boost::context::continuation&&)>)' is ambiguous
             });
              ^
In file included from ./boost/fiber/context.hpp:28:0,
                 from libs/fiber/src/context.cpp:7:
./boost/context/continuation.hpp:469:1: note: candidate: boost::context::continuation boost::context::callcc(std::allocator_arg_t, StackAlloc, Fn&&, Arg ...) [with StackAlloc = boost::context::preallocated; Fn = const boost::context::basic_fixedsize_stack<boost::context::stack_traits>&; Arg = {boost::fibers::context::context(boost::fibers::dispatcher_context_t, const boost::context::preallocated&, const default_stack&, boost::fibers::scheduler*)::<lambda(boost::context::continuation&&)>}]
 callcc( std::allocator_arg_t, StackAlloc salloc, Fn && fn, Arg ... arg) {
 ^
./boost/context/continuation.hpp:483:1: note: candidate: boost::context::continuation boost::context::callcc(std::allocator_arg_t, boost::context::preallocated, StackAlloc, Fn&&, Arg ...) [with StackAlloc = boost::context::basic_fixedsize_stack<boost::context::stack_traits>; Fn = boost::fibers::context::context(boost::fibers::dispatcher_context_t, const boost::context::preallocated&, const default_stack&, boost::fibers::scheduler*)::<lambda(boost::context::continuation&&)>; Arg = {}]
 callcc( std::allocator_arg_t, preallocated palloc, StackAlloc salloc, Fn && fn, Arg ... arg) {
 ^
./boost/context/continuation.hpp:514:1: note: candidate: boost::context::continuation boost::context::callcc(std::allocator_arg_t, boost::context::preallocated, StackAlloc, Fn&&) [with StackAlloc = boost::context::basic_fixedsize_stack<boost::context::stack_traits>; Fn = boost::fibers::context::context(boost::fibers::dispatcher_context_t, const boost::context::preallocated&, const default_stack&, boost::fibers::scheduler*)::<lambda(boost::context::continuation&&)>]
 callcc( std::allocator_arg_t, preallocated palloc, StackAlloc salloc, Fn && fn) {
 ^
./boost/context/continuation.hpp:457:1: note: candidate: boost::context::continuation boost::context::callcc(Fn&&, Arg ...) [with Fn = const std::allocator_arg_t&; Arg = {boost::context::preallocated, boost::context::basic_fixedsize_stack<boost::context::stack_traits>, boost::fibers::context::context(boost::fibers::dispatcher_context_t, const boost::context::preallocated&, const default_stack&, boost::fibers::scheduler*)::<lambda(boost::context::continuation&&)>}; <template-parameter-1-3> = void]
 callcc( Fn && fn, Arg ... arg) {
 ^

outdated doc for fcontext_t?

doc/fcontext.qbk or http://www.boost.org/doc/libs/1_62_0/libs/context/doc/html/context/context.html seem to be outdated for 1.62? Thanks!

Related issue: #33

ExecutionContext v2 Guidance

Hi,
I was hoping to get a some guidance about ExecutionContext v2. Are the following statements correct?

• Execution context v2 is currently a WIP (not part of any Boost release)
• Execution context v2 is planned for Boost 1.61 (if so, is there a timeframe?)
• Execution context v2 is essentially similar in spirt to the symmetric_coro that will/may be removed from Boost.coroutine

Are there any mailing list threads that discuss the semantics of the new execution context, rationale, comparisons with the old.

Thanks!

Missing assembly files on iOS

Hello,

I had some trouble building this library on iOS (armv7/armv7s/x86/x86_64/armv8) and had to patch the build system files in order to add the relevant missing files.

I found this SO thread that saved me days of research, and I came up with the following patches:
patches.zip

Having no notion of Boost.Build, I monkey-patched the file once per arch, and have to apply the correct patch each time (not doing it by hand though).

I was thinking that you would have a better fix than me, and having it fixed upstream would be great!

apply ambiguity due to ADL with upcoming GCC 7

It looks like Boost.Context internally implements an apply facility to invoke a functor on tuple elements.

GCC trunk has recently implemented the std::apply C++1z feature (cppreference), slated for the GCC 7 release.

This means that unqualified calls inside Boost.Context (example) easily end up being ambiguous. Both apply are found during overload resolution, std::apply being found via ADL e.g. as long as an std::tuple specialization is involved. Because they have near identical signatures, none is preferred over the other.

Can't compile libs/context/src/asm/make_arm64_aapcs_macho_gas.S

Hi, I am trying to cross-compile the context library in 1.58 targeting iOS on an OSX host. The library builds fine for arm, but not for the newly introduced arm64. When running with:

./bjam                                                                               
    -j8                                                                                 
    --build-dir=iphone-build                                                
    --stagedir=iphone-build/stage                                      
    --prefix=$PREFIXDIR                                                  
    --toolset=darwin-${IPHONE_SDKVERSION}~iphone 
    toolset=darwin                                                             
    architecture=arm                                                         
    target-os=iphone                                                          
    address-model=64                                                       
    binary-format=mach-o                                                  
    abi=aapcs                                                                     
    macosx-version=iphone-${IPHONE_SDKVERSION}  
    define=_LITTLE_ENDIAN                                            
    link=static                                                                     
    threading=multi                                                            
    stage

I get a lot of those:

libs/context/src/asm/make_arm64_aapcs_macho_gas.S:54:21: error: unexpected token in argument list
; shift address in x0 (allocated stack) to lower 16 byte boundary
^
libs/context/src/asm/make_arm64_aapcs_macho_gas.S:55:17: error: unexpected token in operand
and x0, x0, ~0xF
^
libs/context/src/asm/make_arm64_aapcs_macho_gas.S:57:21: error: unexpected token in argument list
; reserve space for context-data on context-stack
^
libs/context/src/asm/make_arm64_aapcs_macho_gas.S:58:9: error: invalid operand for instruction
sub x0, x0, #0xb0
^
and so on...

And last but not least, thank you for this great library. Keep up the good work!

Weird issue with msvc assembler

Hi,

I have a project that is built with msvc (express 2015) via cl, ml, link etc tools from the command line, and was having all sorts of problems getting boost context code to work with it - make_fcontext was just crashing everytime.

Finally narrowed it down to the stack layout being messed up - the first parameter passed to make_fcontext was not located at [esp+4] but at [esp+8]!

Finally narrowed that down to the 'PROC' declaration in the ASM:

make_fcontext PROC BOOST_CONTEXT_EXPORT

I have no idea what the 'BOOST_CONTEXT_EXPORT' bit is supposed to do, but removing it fixed the problem entirely. I also removed it from jump_context and ontop_context (whatever that does!).

It may well be I'm missing an ML option on the command line or something as I would have assumed people were using this with msvc all over the place. Anyone know what's up?

Love the low level boost::context stuff by the way and have used it on a ton of targets. Would love to see it in WASM too eventually - please talk the WASM guys into it!

Bye!
Mark

Testsuite fails on ppc64el

Running the testsuite on ppc64el fails with the following error (this is commit 93da162).

testing.capture-output ../../../bin.v2/libs/context/test/test_callcc_asm.test/gcc-7/release/link-static/threadapi-pthread/threading-multi/test_callcc_asm.run
====== BEGIN OUTPUT ======
Running 11 test cases...
unknown location(0): fatal error: in "Boost.Context: callcc test suite/_test_move": memory access violation at address: 0x00000000: no mapping at fault address
test_callcc.cpp(147): last checkpoint

*** 1 failure is detected in the test module "Master Test Suite"

EXIT STATUS: 201
====== END OUTPUT ======

Running fc fails with:

testing.capture-output ../../../bin.v2/libs/context/test/test_fcontext.test/gcc-7/release/link-static/threadapi-pthread/threading-multi/test_fcontext.run
====== BEGIN OUTPUT ======
Running 12 test cases...
f1: entered
unknown location(0): fatal error: in "Boost.Context: context test suite/_test_ontop": memory access violation at address: 0x3fffa94c4fb8: invalid permissions
test_fcontext.cpp(308): last checkpoint

*** 1 failure is detected in the test module "Master Test Suite"

EXIT STATUS: 201
====== END OUTPUT ======