> > > 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.
> >
> > I don't see how fork() semantics can be preserved unless
> > the stack regions are replicated (copy-on-write) on a fork().
> > Under ATT and BSD Unix (which is where I did most of
> > my kernel hacking in the old days) that was the *only*
> > way to get a new kernel thread, so it was "obvious"
> > that my proposed hack would work. Linux does have
> > the clone() function as well, and if LinuxThreads are
> > implemented in terms of clone(foo, stakptr, CLONE_VM, arg),
> > you are correct, the proposed scheme would not work
> > without modification.
>
> Which it is. Fork shares no memory regions;
Oh, come on. If it doesn't share text regions, it's completely
brain dead!
> vfork/clone share all memory regions. AFAIK there is no
> share-heap-but-not-stack option in Linux.
Yeah. Not that it matters, but I had misremebered there being
finer grained control than that on clone(). Probably confused
it with something that someone overlaid on Mach once upon a time...
Anyway, do you see a hole or a serious performance
problem with my modified proposal (explicit mmap()
to create the necessary storage)?
Regards,
Kevin K.
