lkml.org 
[lkml]   [1999]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.115 / U:0.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site