On 12/14/2011 04:00 PM, Ian Lance Taylor wrote:
> > This implementation relies on the functions getcontext, setcontext, and
> > makecontext. If there are systems which don't have those, getcontext
> > and setcontext can be replaced by setjmp and longjmp, but there is no
> > obvious replacement for makecontext. I think that will have to be
> > implemented using processor-specific code, as it needs to set the stack
> > pointer to point to a new stack, and I don't know how to do that in a
> > portable processor-independent manner without using makecontext.
>
> ARM glibc does not implement these functions, so we have the same
> problem in QEMU. (On top of this, there is no way that alternate
> stacks can work on OpenBSD, so we still have one coroutine per
> thread).
The other Go compiler already supports OpenBSD, so it must be possible
in some sense.
Do they have specialised code for OpenBSD? I said "it cannot work" in
the sense that:
- *context functions are not there;
- sigaltstack always returns EINVAL when using threads;
- the threads are identified by the runtime from their stack pointer, so
you risk confusing the runtime very much if you switch between coroutines.
I don't have any problem using a dedicated signal. That's an
interesting approach. I wonder what the relative performance would be.
You can look at the code at git://github.com/bonzini/qemu.git, branch
coroutine-fix.
Paolo
