Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU |
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
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |