Re: thread-ready ABIs

[Daniel Jacobowitz <dan@debian.org>]

On Tue, Jan 22, 2002 at 06:47:55PM +0100, Kevin D. Kissell wrote:
> > > 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, you didn't read my message.  The per-thread memory
> would be allocated *after* the clone() in pthread_create().
> More specifically, pthread_create() would set it up so that
> the function passed to clone for invocation was in fact a
> wrapper that sets up the memory and thread data before
> invoking the application function passed to pthread_create().
> 
> Now, if the idea is that the clone() system call is supposed
> to cause the thread to be born, like Athena, full-grown from
> the head of Zeus, with the analog to the thread register
> already set up when it leaves the kernel, then I would be inclined
> to concede that we need to change the ABI, the kernel, and
> compilers, and I would ask just what we get for our trouble.
> But if we are permitted the pthreads abstraction, there's a
> lot that can be done transparently.

No, you didn't read my manpage quote, Kevin.  Or we're just talking
past each other.  The problem is not that existing mappings are shared,
but that "any memory mapping or unmapping performed with mmap(2)
or munmap(2) by the child or calling process also affects the other
process".  That is, if the child maps some private storage, the parent
will see it too.  Thus we can not use the private storage as a
thread-local storage unless we already have some thread-local way to
say where it is for this particular thread, and we're back where we
started.

Does that make sense, or am I missing your objection?

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