Messages in this thread | | | Subject | Re: popen/pclose problem in Linux 2.2.x with vfork/glibc 2.1 | Date | Mon, 29 Mar 1999 09:03:43 -0400 | From | Horst von Brand <> |
| |
"Albert D. Cahalan" <acahalan@cs.uml.edu> said: > Horst von Brand writes: > > "Albert D. Cahalan" <acahalan@cs.uml.edu> said: > >> The standard allows a range of behavior, including the extremes > >> of "just like fork" and "nothing useful works". Extremes are bad.
> > 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/
| |