Looks [1] like http://byuu.org/library/libco/ (mentioned below) might work on iOS. I would definitely be interested in fiber libs that are confirmed to work on iOS and/or Android if anyone knows any. libco looks like it might fit the bill. But, it's not completely clear and I have not tried it.
libco relies on being able to map WX pages for a rather silly reason[1], so it won't run on iOS without some work.
[1] The author didn't like requiring assemblers to build his projects, so instead the coroutine switch machine code is embedded in the binary as a byte array, which is then copied to a page with WX permissions when the library is initialized.
Why do you feel [1] is a silly reason? You can build my software right now in one step: "install TDM-GCC"; anything additional complicates things and reduces portability. There's also versions that don't require assembler code at all (setjmp/longjmp version), and you can also make an ios.c version that has inline assembler since that target will only ever have a single compiler anyway.
Ironic in light of your comments on the OpenBSD forced W^X thing, but I happen to agree that strict W^X should be used everywhere possible. It may not matter for higan (though it would be funny to see someone exploit it), but it could be a deal breaker for more security-conscious projects that might want to use libco (say, for a cothreaded server).
As for assemblers, I just don't see how requiring gas or maybe NASM/YASM for x86 would complicate the build process so much. Heck, gas is a dependency of gcc. The only problem I see is for Visual Studio users, which could be solved with using NASM/YASM for Windows (which is not really a big deal when the co_swap_function has to be different due to the calling conventions anyway), or a separate MASM implementation for Visual Studio (giving you duplicate implementations with VS Windows and gcc Windows on x86 and x86_64 respectively).
I know you're consistent with your views on code clarity and that this is a hobby for you etc, but libco seems like a tiny, static enough library that it would make sense to accept a little ugliness in order to Do The Right Thing™.
(PS: Thank you for higan, I've learned so much from it over the years.)
> I happen to agree that strict W^X should be used everywhere possible
I agree. I just feel there are exceptions, one of which is dynamic recompiling emulators.
> it could be a deal breaker for more security-conscious projects that might want to use libco (say, for a cothreaded server).
I was worried that since mprotect works on entire pages, that by clearing the write flag, I might be removing writability to certain variables. But, theoretically, static char arrays should always end up in the .data section, so it should be fine. Still feel uneasy about it.
Unfortunately, there's no POSIX way to read the current protections, so I can't just apply |X; plus that's probably not safe.
I could allocate three _SC_PAGESIZE blocks of memory (for alignment), mark the middle block R|W, copy the function to it, and then mark the block R|X. As long as OpenBSD allows those two calls, that should work.
> it would make sense to accept a little ugliness in order to Do The Right Thing™
I don't see how requiring Windows users to download yasm (64-bit) or nasm (32-bit) is doing the right thing. Every single additional step required to compile my software will result in more and more people giving up or not bothering.
We ended up integrating some Boost ARM assembly code that did the trick (both 32 and 64 bit). I don't personally have the details because I didn't do the integration but after a few iterations and some tweaks it worked for us.
It has an ARM implementation, but there are lots of subtle ARM variations. You'd probably have to tweak it a tad, but the core ARM cothread switching code is a mere three instructions, so it shouldn't be too hard to adapt:
[1] http://libretro.com/forums/archive/index.php?t-785.html