Technical Linux questions

[Nathan Meyers]

On Sat, Feb 22, 2003 at 03:59:13PM +0000, John Chambers wrote:
> Nathan Meyers wrote:
> | On Sat, Feb 22, 2003 at 04:49:42AM +0000, John Chambers wrote:
> | > Which reminds me of  a  question  I've  never  really  seen
> | > answered:   How  exactly  do kernel threads differ from the
> | > result of a vfork() call?
> |
> | In intent, if nothing else. Threads are intended to allow for multiple
> | threads of execution in the same process space; vfork is intended to
> | spawn a child whose only purpose is to immediately exec() a different
> | executable. One description I found somewhere - I'm not sure how accurate
> | - is that the parent blocks until the new child exec()s a new executable.
> 
> On the projects where I used vfork(), I never saw this.  It
> would have been a showstopper, of course, and reported as a
> fatal bug.  I do recall warnings in  man  pages  about  the
> dangers  of  the  child  process changing memory before the
> exec; this implies (but doesn't prove) that the  parent  is
> running. But it's moot now that vfork is widely implemented
> as fork, so it can't be used if you want portability.
> 
> | There's a lot of context management needed to make threads work
> | properly. Given its limited functionality, vfork() doesn't have to
> | provide such management - that's more than a documentation difference :-).
> 
> While this is true for a lot of programs, it isn't true for
> all.   And  in  any  case, system calls are rarely actually
> needed for much of this. The work can be done in user space
> (though  some  sync  primitives will require some judicious
> use of machine language to get atomicity).

You're welcome to rely on non-portable behavior any time you can get
away with it. For many developers, braving the thickets of a portable
(if complex) API like pthreads is worth the trouble it saves later. Even
better is to work in an environment like Java that abstracts out a
lot of the complexity and crappy little details (like whether vfork()
is really creating threads :-) developers must deal with.

Nathan