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 <kryn@???> 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
>