This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Go patch committed: Multiplex goroutines onto OS threads
- From: Ian Lance Taylor <iant at google dot com>
- To: Paolo Bonzini <bonzini at gnu dot org>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Peter Maydell <peter dot maydell at linaro dot org>
- Date: Wed, 14 Dec 2011 07:00:51 -0800
- Subject: Re: Go patch committed: Multiplex goroutines onto OS threads
- References: <mcr1uss6bpn.fsf@dhcp-172-18-216-180.mtv.corp.google.com> <4EE8B206.3020000@gnu.org>
Paolo Bonzini <bonzini@gnu.org> writes:
> On 11/28/2011 06:46 AM, 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.
> For QEMU, I tried replacing for makecontext using sigaltstack. It
> works on Linux but it needs a dedicated signal, so it is likely
> inappropriate for libgo. It would also need to be tested across many
> operating systems because it may trigger subtleties in other OSes.
I don't have any problem using a dedicated signal. That's an
interesting approach. I wonder what the relative performance would be.
Anyhow, makecontext is easy to write in a system specific manner. It
doesn't even have to be written in assembler, though getcontext and
setcontext do have to be assembler. Why not just implement them for
ARM?
Ian