Le 15/06/2016 18:57, Edward Bartolo a écrit :
> 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.
Yes, some, the unavoidable to ensure childhood hiereachy, fair
process scheduling and sensible I/O operation.
Yet the paradigm, from the programatic pov is they are identical, appart
for hierarchy. Record locks and outstanding asynchronous IOs are not
commonly used and who would do that just before forking?
Didier
::
Re: [DNG] Custom OS initiator. In n…
