got it, thanks. so the fork just starts on the line after fork for the child process?
Thanks, Tyler Littlefield Web: tysdomain.com email: ty...@tysdomain.com My programs don't have bugs, they're called randomly added features. ----- Original Message ----- From: Thomas Hruska To: c-prog@yahoogroups.com Sent: Tuesday, April 07, 2009 10:29 PM Subject: Re: [c-prog] C language Tyler Littlefield wrote: > I do have a question regarding that though. > If I were to write fork, I'd make it take a function to call when the process is recreated. I have seen a bunch of examples of fork, but it looks like after they fork it starts after the fork call? or how does that work. To answer your question: fork() operates by copying the working set to a new pid. Actually, for performance-reasons, it supposedly doesn't actually copy anything but marks each memory block as a copy-on-write operation...but that is an implementation detail and hardware-specific. For all intents and purposes from the programmer's perspective, the entire process is copied byte for byte by the OS (in kernel mode). fork() then returns 0 for the child process and the pid for the parent process. The two processes are quite literally identical right up to that point (including things like open sockets, file descriptors, etc.). How fork() determines it is the child process vs. parent process is likely a comparison of the two process IDs/pointers/handles to what it thinks it is (based on a previous retrieval prior to the actual copy) or the kernel simply keeps track. One of the two. There is no need to have a callback function as the processes are identical and there is a way to differentiate between child and parent. -- Thomas Hruska CubicleSoft President Ph: 517-803-4197 *NEW* MyTaskFocus 1.1 Get on task. Stay on task. http://www.CubicleSoft.com/MyTaskFocus/ [Non-text portions of this message have been removed]