This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: user-space threads
- From: Tom Tromey <tromey at redhat dot com>
- To: Adam Megacz <adam at megacz dot com>
- Cc: java at gcc dot gnu dot org
- Date: 23 Oct 2002 16:35:32 -0600
- Subject: Re: user-space threads
- References: <86elah586q.fsf@nowhere.com>
- Reply-to: tromey at redhat dot com
>>>>> "Adam" == Adam Megacz <adam@megacz.com> writes:
Adam> Is it possible to implement gcj's threading entirely in userspace,
Adam> using nonblocking I/O and alarm()?
Yes.
We've done about 50% of this before, in the distant past (1997 or 98).
This was the old qthreads code; there might even be a relic or two of
it still in the tree.
We had cooperative user-level threads. We didn't try to solve the
nonblocking I/O problem, but only because the customer didn't need
that.
Adam> Does the gc make any assumptions about threading that would
Adam> break if I used this technique?
The GC wants to be able to see the contents of all the stacks. So you
need to write some code that will interface between the GC and the
user thread implementation. I wrote this code for our implementation,
way back. It is easy.
I remembered a comment from libgcj dating to these days. From
prims.cc:
// FIXME: These variables are static so that they will be
// automatically scanned by the Boehm collector. This is needed
// because with qthreads the collector won't scan the initial stack --
// it will only scan the qthreads stacks.
This was needed because our initial stack was the ordinary system
stack. Once qthreads started, we didn't tell the GC about the system
stack (which was lying dormant). Objects appearing only on that stack
could be collected, so we just forced them elsewhere. Gross.
Tom