:: Re: [DNG] Custom OS initiator. In n…
Top Page
Delete this message
Reply to this message
Author: Edward Bartolo
Date:  
To: Didier Kryn
CC: dng
Subject: Re: [DNG] Custom OS initiator. In need of some hints...
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

>