> 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?
It doen't necessarily make *sense*, in that it seems to
be a pretty crippled memory model ;-) but I do see your
objection. Sorry to have seemed dense, I'm doing several
things at once on a couple of screens this evening and
reading too quickly. I had misread that as underscoring
that the effects of mmaps() *prior* to the clone() were
inherited. Feh. Well, we aren't likely to have the luxury
of fixing the underlying design of pthreads for Linux
to use a fork()-based model with explicit sharing
(which has its own problems, of course), so we may well
be looking at ABI abuse. I was really, really, hoping
to avoid that, in that gcc/Linux is far from the only user
(and commercially speaking, far from being the most
important user) of the ABI, and any change that breaks
backward compatibility and cross-platform compatibility
would be a Very Bad Thing.
More on this later, and thanks for your (civil) comments,
Kevin K.
