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
