Re: thread-ready ABIs

[Daniel Jacobowitz <dan@debian.org>]

On Tue, Jan 22, 2002 at 06:34:42PM +0100, Kevin D. Kissell wrote:
> > > > 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!

They aren't shared, they're duplicated.  They use the same physical
memory, and the same virtual addresses, but the page table entries are
separate.  That's what I meant.  No copy of the page table is common on
fork(), AFAIK.

> > 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)?

Same problem as with clone.  I recommend the clone manpage; it says:

       CLONE_VM
              If CLONE_VM is set, the calling process and the child processes run in the same
              memory space.  In particular, memory writes performed by the calling process or
              by the child process are also visible in the other process.  Moreover, any mem­
              ory mapping or unmapping performed with mmap(2) or munmap(2) by  the  child  or
              calling process also affects the other process.

              If CLONE_VM is not set, the child process runs in a separate copy of the memory
              space of the calling process at the time of clone.  Memory writes or file  map­
              pings/unmappings  performed by one of the processes do not affect the other, as
              with fork(2).

That is, if any memory OR MAPPING is shared, they all are.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer