Re: Go patch committed: Multiplex goroutines onto OS threads

[Paolo Bonzini <bonzini at gnu dot org>]

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