> > The standard allows "nothing useful works", so a portable program (or
> > library) has to work in that case too, and the kernel implementers can
> > rightly give you exactly that if convenient.
> Kernel implementers can indeed produce a crappy kernel that meets the
> letter of a standard. Why would they want to make a crappy kernel?
Because that's all they _have_ to do to conform to the letter of the
standard. Standards aren't written into thin air, careful consideration is
given to what might be impossible (or very dificult, or just expensive) to
do, and consider the possibility of letting implementors off the hook where
reasonable. That's the "convenient" in my statement above.
In this particular case (vfork(2) use in glibc) you should note:
- glibc is _not_ just for Linux, it has to work on every POSIX (and perhaps
even less) platform. So it can not assume things that "usually work" or
"reasonable implementations provide it"
- You _have_ fork(2) for the cases where vfork(2) isn't enough. Cut the
kernel developers some slack here: They implement what is _efficient_ to
do _right_ for vfork(2).
[...]
> Nope, fork() doesn't share the address space.
Neither does vfork(2), as it is allowed to make vfork(2) simply an alias
for fork(2). If you want shared address spaces, use threads.
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/