Messages in this thread | | | Date | Wed, 3 Nov 1999 07:55:59 -0500 | From | "Theodore Y. Ts'o" <> | Subject | Re: vfork |
| |
Date: Wed, 03 Nov 1999 01:46:00 +0000 From: dancer@zeor.simegen.com
> I think you were being a little bit too harsh, myself, but it is true > that warning people that using it compromises the portability of their > programs is perfectly fair.
Concur, all round. However, we've now had 'vfork() == fork()' being generally advertised for some time. I know programmers, therefore (many of whom I'd not care to share an office with, but that's another thing entirely) who reflexively have used vfork() everywhere 'because it's the same as fork, but might be better than fork one day'.
Agreed, but that's silly. If was going "to be better than fork one day", it would do so by assuming the old BSD semantics (and that does have some slight performance penefits even with COW).
However, if they use vfork() like fork() in some situation where BSD 4.3 vfork() would break, on the vague assumption that vfork() will change in some way that's better-but-without-any-of-the-limitations-of-old-vfork, they're just being stupid, and they deserve everything they get.
Post _big_ warnings. Some things will break. Things that should have been written differently to begin with, mind you.
Sigh.... too bad we can't give programmers electric shocks each time they pull such wild leaps of illogic.
- Ted
- 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/
| |