On Tue, Jan 22, 2002 at 05:05:45PM +0100, Kevin D. Kissell wrote:
> > In any case, that's not the real problem. Linux user threads do not
> > have true separate stacks. They share their _entire_ address space;
> > the stacks are all bounded (default is 2MB) and grouped together at the
> > top of the available memory region.
> Exactly. But if all we all we are worried about is thread
> specific data for user threads multiplexed on exactly
> one kernel thread, we could probably get by with a
> simple global variable for the thread pointer for the
> current user thread running in the process. It's the
> case of multiple user threads running within multiple
> *kernel* threads (e.g. created by fork()) that complicates
> things, and makes people want to use a register
> or other storage resource associated with exactly one
> kernel thread (and CPU). A permanently assigned
> register, as we have seen, creates various complications,
> so I'm looking for another kernel-thread-specific resource,
> of which I believe the stack region is the best candidate.
> Each process/task/program would have a single global
> variable, which points to a common address in the
> stack region of each kernel thread, which is used
> to store the address of the user-thread-specific
> data of the user thread executing on that kernel thread.
Perhaps I'm mangling terminology. LinuxThreads is a one-to-one mapping
of kernel threads to user threads. All the kernel threads, and thus
all the user threads, share the same memory region - including the
stack region. Their stacks are differentiated solely by different
values in the stack pointer register. Thus I don't think what you're
suggesting is possible.
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer