Messages in this thread | | | From | "Albert D. Cahalan" <> | Subject | Re: popen/pclose problem in Linux 2.2.x with vfork/glibc 2.1 | Date | Sun, 28 Mar 1999 17:18:41 -0500 (EST) |
| |
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?
Hey, Windows NT is POSIX. Is that good enough for you?
>> What people seem to want most: >> open, close, dup, dup2, _exit, execve, stat, fstat, lstat, >> link, unlink, rename, lseek, fsync, read, write, socket... > > Then use fork(2). vfork(2) is just a lightweight (half)implementation of > fork(2) for cases where you can get away with it.
Nope, fork() doesn't share the address space.
There isn't any reason to have a useless system call that nobody can stand to use. It is completely reasonable to have a vfork() that lets the child set up IO before the exec, but still shares address space.
- 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/
| |