Hi, I am saying the child and parent at not the same at the point fork() executes for the following reasons taken from "man 2 fork".
Quote taken from "man 2 fork": (Please not the *except*) << The new process, referred to as the child, is an exact duplicate of the calling process, referred to as the parent, except for the following points: * The child has its own unique process ID, and this PID does not match the ID of any existing process group (setpgid(2)). * The child's parent process ID is the same as the parent's process ID. * The child does not inherit its parent's memory locks (mlock(2), mlockall(2)). * Process resource utilizations (getrusage(2)) and CPU time counters (times(2)) are reset to zero in the child. * The child's set of pending signals is initially empty (sigpend‐ ing(2)). * The child does not inherit semaphore adjustments from its parent (semop(2)). * The child does not inherit process-associated record locks from its parent (fcntl(2)). (On the other hand, it does inherit fcntl(2) open file description locks and flock(2) locks from its parent.) * The child does not inherit timers from its parent (setitimer(2), alarm(2), timer_create(2)). * The child does not inherit outstanding asynchronous I/O operations from its parent (aio_read(3), aio_write(3)), nor does it inherit any asynchronous I/O contexts from its parent (see io_setup(2)). >> Further down the same manpage continues to list more differences. This is why I am saying the child and parent differ in some aspects. Edward On 15/06/2016, Didier Kryn <k...@in2p3.fr> wrote: > Le 14/06/2016 19:24, Edward Bartolo a écrit : >> To me fork() looks much more than simply a function that does >> some processing returning a result as it looks more like an >> instruction directed at the kernel scheduler to split the process into >> a parent and child that are not equal in all respects. > They are *equal* in absolutely all respects except a bookkeeping > detail: the kernel decides that one of them is the parent and the other > is the child. And fork() informs them of this status by the means of its > return value. Appart from this detail, every variable has the same value > and the program-counter is the same. The image carried by the word > "fork" is very explicit: the two processes are the same in the past and > different in the future. And you are free to decide which of them will > do what - but, ok, you can wait() a child but not a parent. > > Didier > _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng