bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Inquiry about GCC Summer Of Code project idea.


From: Fotis Koutoulakis
Subject: Re: Inquiry about GCC Summer Of Code project idea.
Date: Fri, 3 May 2013 21:23:49 +0300

Hello!

First of all I would like to thank you everyone for your input. I really appreciate it.

I would also like you to know that I managed to study the material that you all have linked to (or that is generally available online on the project's wikis of that matter) and I managed to come up with a proposal for the project idea that got me hooked in the beginning.

A link to it can be found here: https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/nlightnfotis/1 (I hope it is publicly visible, it seems to me it is).

Of course, I am more than open to comments/criticism as well as clarifications.

Last but not least, I would like to thank you all for your time, as well as grab the chance to apologize for my late proposal and my late answer.

Sincerely,
Fotis Koutoulakis


On Tue, Apr 30, 2013 at 4:58 PM, Ian Lance Taylor <iant@google.com> wrote:
On Tue, Apr 30, 2013 at 6:53 AM, Thomas Schwinge
<thomas@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



--
Fotis 'NlightNFotis' Koutoulakis

- "Non semper aestas erit; venit hiems."

reply via email to

[Prev in Thread] Current Thread [Next in Thread]