On Tue, Apr 30, 2013 at 6:53 AM, Thomas Schwinge <tho...@codesourcery.com> wrote: > > On <http://darnassus.sceen.net/~hurd-web/open_issues/gccgo/> I have just > updated/posted a getcontext/makecontext/setcontext/swapcontext usage > analysis. This might constitute a "road block": the Hurd currently does > not allow for changing the stack of a process/thread. Implemented a > while before TLS/__thread variables came along, we have a legacy > threadvar mechanism implemented in glibc, which places thread-local > variables (errno, for example) at the bottom of a thread's stack. Then, > when switching the stack of a thread, glibc can't locate these anymore, > and "bad things" happen. This threadvar mechanism is scheduled to go > away (we do implement TLS by now), but when working on that I hit "some > issues" and have not yet found the time to continue. > <http://darnassus.sceen.net/~hurd-web/open_issues/glibc/t/tls-threadvar/> > and > <http://news.gmane.org/find-root.php?message_id=%3c878vdyqht3%2Efsf%40kepler%2Eschwinge%2Ehomeip%2Enet%3e> > have the details. > > Now, it seems the GCC Go port is implemented in a way that makes > extensive use of switching stacks. So until this threadvar issue is > resolved, there is probably no way to really proceed with the GCC Go port > for GNU Hurd -- unless maybe this stack switching could be hacked around > (Ian?), say, by limiting oneself to not using Goroutines and similar > "specials", and having a custom/minimal Go runtime startup.
Go does require switching stacks. A port of Go that doesn't support goroutines would be useless--nothing in the standard library would work. It might be possible to use pthread_getspecific and friends instead of TLS. Ian
