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 |
I am not exactly certain of the Linux code since I have not checked the kernel. On HP-UX, vfork() is an alias of fork(). On Tru64 Unix, vfork() and fork() are separate system calles, but effectively do the same thing. Today fork() and vfork() are implemented as copy-on-write. which means that the parent and child processes share the same physical virtual memory. The process creation is simply a mapping operation WRT: memory. Certainly the child will get a new stack because of the return value from vfork(). On the Purify project, the fork() and vfork() code was very convoluted because on some platforms, vfork() is broken and on others it does not actually exist, and the vfork() wrapper in libc simply calls the fork() system call. Remember that a pthread_create() does not create another process. The new thread exists in the same process space as the parent. This an exec() system call from within a thread will replace the entire process. I've done that. It is legal to fork() or vfork() from within a thread. Also, while each thread has its own priority and scheduling method, that exists within the process' priority. The bottom line is that threading adds a lighter weight method for achieving paralellism within a process. No new memory is created (except possibly stack and thread control block). All memory (other than stack, TCB, and TLS) is shared among all the threads. That is why many functions in the C runtime library (such as ctime), are not threadsafe unless the library designers have come up with a threadsafe scheme. Even memory acquired by malloc() is available to other threads. And, the implementation of kernel threads varies among systems. On Sat, 22 Feb 2003 15:15:20 UTC John Chambers <jc at trillian.mit.edu> wrote: > True, but this doesn't answer the question. The above > exactly describes the original vfork(), which created a new > process with its own stack but with the same data segment > as the parent. It's true that the intent was to make the > fork+exec sequence faster by saving a copy of memory that > was to be discarded. But in fact it could be used to create > multiple control points within the same program. I did this > on a couple of projects. Some sync operations were needed, > of course, but that's a different question from the > creation of "threads" and context switching, and can be > done in user space without any other system calls. > > It's also true that vfork() is sometimes implemented as an > alias of fork(). This is rather a pity, as it interferes > with portability. I'd be tempted to provide an #ifdef that > overrides vfork with a routine that creates a kernel thread > on systems where vfork isn't implemented properly. > > So far, it seems that we merely have two names for the same > concept. If by "vfork" you mean the original routine that > produced a new stack but shared the rest of the parent's > memory, there's the question of what a kernel thread does > that's materially different. (And note that listing other > tools in a "threads" package isn't an answer. You can add a > library of routines to anything.) > > If I were to call pthread_create() followed by execve(), is > the result any different than fork+exec or vfork+exec? On a > system with a true vfork(), is there any of the pthread > library's functions that couldn't be implemented? It's > difficult to find answers such questions in the man pages. > The words are very different, but they seem to describe > something quite similar, if not identical. > > One question that came up on a project: If a process calls > vfork() and one of the processes then does malloc(), is the > new memory accessible to both processes? The answer seems > to have been "Try it and find out." But this only tells you > the answer on the machine you test it on; it doesn't tell > you whether your code will work on another system, or after > an upgrade on the same machine. (Actually, a bit of digging > seems to turn up no clear answer to this question for > threads, either. Saying that malloc() is "thread safe" is > not an answer at all, since it doesn't tell you what the > behavior is or whether it's portable. ;-) > > _______________________________________________ > Discuss mailing list > Discuss at blu.org > http://www.blu.org/mailman/listinfo/discuss > -- Jerry Feldman <gaf at blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.blu.org/pipermail/discuss/attachments/20030222/d1543975/attachment.sig>
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |