Discussion:
the author means what?
(too old to reply)
G G
2019-07-14 21:00:04 UTC
Permalink
from book: operating systems design and implementation

"The fork call returns a value, which is zero in the child and
equal to the child's process identifier or PID in the parent.
Using the returned PID, the two processes can see which
one is the parent process and which one is the child process."
-------

so, if you ask the child for its id it would return 0,
but it you ask the parent, that started that child,
the parent would return, a non 0, PID value?
Barry Margolin
2019-07-14 21:44:06 UTC
Permalink
Post by G G
from book: operating systems design and implementation
"The fork call returns a value, which is zero in the child and
equal to the child's process identifier or PID in the parent.
Using the returned PID, the two processes can see which
one is the parent process and which one is the child process."
-------
so, if you ask the child for its id it would return 0,
but it you ask the parent, that started that child,
the parent would return, a non 0, PID value?
You don't ask the process for its ID, the fork() call returns a value
that you can use.

pid = fork();
if (pid == 0) {
printf("I'm the child\n");
} else if (pid > 0) {
printf("I'm the parent, I created a child with PID = %d\n", pid);
} else {
perror("fork failed");
}
--
Barry Margolin, ***@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Keith Thompson
2019-07-14 22:57:45 UTC
Permalink
Post by Barry Margolin
Post by G G
from book: operating systems design and implementation
"The fork call returns a value, which is zero in the child and
equal to the child's process identifier or PID in the parent.
Using the returned PID, the two processes can see which
one is the parent process and which one is the child process."
-------
so, if you ask the child for its id it would return 0,
but it you ask the parent, that started that child,
the parent would return, a non 0, PID value?
You don't ask the process for its ID, the fork() call returns a value
that you can use.
pid = fork();
if (pid == 0) {
printf("I'm the child\n");
} else if (pid > 0) {
printf("I'm the parent, I created a child with PID = %d\n", pid);
} else {
perror("fork failed");
}
Expanding on that, the reason fork() returns the values it does is that
it gives the caller information that can't be obtained by other means.

For the child, it returns 0 as an indication of "you're the child".
The child process can obtain its own and its parent's process ids
if it needs them by calling getpid() and getppid(), respectively.

For the parent, it returns the process id of the child because that
information isn't otherwise available. There's no getchildpid() function
because a process can have multiple children.
--
Keith Thompson (The_Other_Keith) kst-***@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
Lew Pitcher
2019-07-14 23:31:38 UTC
Permalink
Post by G G
from book: operating systems design and implementation
"The fork call returns a value, which is zero in the child and
equal to the child's process identifier or PID in the parent.
Using the returned PID, the two processes can see which
one is the parent process and which one is the child process."
-------
so, if you ask the child for its id it would return 0,
No, that's not what fork() does. You do not call fork() to passively obtain
an indication of whether the process is a child or not (actually, outside of
process 1, /all/ processes are child processes of some other process).
Instead, you call fork() to actively /create/ a child process.
Post by G G
but it you ask the parent, that started that child,
the parent would return, a non 0, PID value?
Let me explain...


In the beginning, there was a process. It executed it's code and updated
it's data in relative isolation.

+--- Process ---+
| ... |
| -> ... |
| pid=fork();|
| if (pid==0)|
| ... |
+---------------+

That is, until it executed a fork() system call.

+--- Process ---+
| ... |
| ... |
| -> pid=fork();|
| if (pid==0)|
| ... |
+---------------+

The system, seeing that the process was in the process of executing a fork()
call, created a new, second process, with a copy of code and data as was
present in the original process at the time it called fork().

+--- Process ---+ +--- Process ---+
| ... | | ... |
| ... | | ... |
| -> pid=fork();| | -> pid=fork();|
| if (pid==0)| | if (pid==0)|
| ... | | ... |
+---------------+ +---------------+

Now, both processes were identical, and that wouldn't do. How was each
process to determine what it's job was?

Well, the OS had a solution. To one of the processes (the process it had
created in response to the fork() syscall) it would return a value of 0 from
fork(), and to the other process (the process that had been existance before
the fork() call), it would provide the PID of the /new/ process as the
return value from fork().

This way, each process could test the value returned by the fork() system
call to determine whether it was the child process (with the zero return
value) or the parent process (with the value of the child's PID).

+--- Process ---+ +--- Process ---+
| ... | | ... |
| ... | | ... |
| pid=fork();| | pid=fork();|
| -> if (pid==0)| | -> if (pid==0)|
| ... | | ... |
+---------------+ +---------------+

So on they executed, the parent process to do parent process things, knowing
that it was the parent process by the fact that it had received the child's
PID as the return value from fork(), and the child process to do child
process things, knowing that it the child process by the fact that it had
received a zero as the return value from fork().
--
Lew Pitcher
"In Skills, We Trust"
Scott Lurndal
2019-07-15 13:19:30 UTC
Permalink
Post by Lew Pitcher
The system, seeing that the process was in the process of executing a fork()
call, created a new, second process, with a copy of code and data as was
present in the original process at the time it called fork().
+--- Process ---+ +--- Process ---+
| ... | | ... |
| ... | | ... |
| -> pid=fork();| | -> pid=fork();|
| if (pid==0)| | if (pid==0)|
| ... | | ... |
+---------------+ +---------------+
Now, both processes were identical, and that wouldn't do. How was each
process to determine what it's job was?
Well, the OS had a solution. To one of the processes (the process it had
created in response to the fork() syscall) it would return a value of 0 from
fork(), and to the other process (the process that had been existance before
the fork() call), it would provide the PID of the /new/ process as the
return value from fork().
And the way it was implemented in Unix V6 was rather clever, and annotated
with a comment from DMR "You are not expected to understand this".
Helmut Waitzmann
2019-07-15 08:19:22 UTC
Permalink
Post by G G
from book: operating systems design and implementation
"The fork call returns a value, which is zero in the child and
equal to the child's process identifier or PID in the parent.
Using the returned PID, the two processes can see which
one is the parent process and which one is the child process."
-------
so, if you ask the child for its id it would return 0,
but it you ask the parent, that started that child,
the parent would return, a non 0, PID value?
If you let the child process examine the return value of the
fork() system call, it will see the value 0.

If you let the parent process examine the return value of the
fork() system call, either it will see the value -1 (if the system
call failed, i. e. could not create a child process) or it will
see a value neither -1 nor 0, which is the process id of the newly
created child process (if the system call succeeded).

Why is this feature important?

At the time, when the fork() system call returns, the child
process (if it has successfully been created) as well as the
parent process inherently run the same program code. In order to
have both processes do different things, one has to code a runtime
test on the return value of the fork() system call:

IF
I am the child process (i. e. the return value of the fork()
system call equals 0),
THEN
do the task of the child process
ELSE
do the task of the parent process:
check whether a child process has successfully been created:
IF
that's not the case (i. e. the return value of the fork()
system call equals -1),
THEN
do some kind of error recovery
ELSE
continue the task of the parent process.

=> The supplied program code comprises the task of the parent as
well as that of the child. The decision, which branch of the code
should be executed, is made by examining the return value of the
fork() system call.
m***@gmail.com
2020-09-21 11:43:06 UTC
Permalink
Post by G G
from book: operating systems design and implementation
"The fork call returns a value, which is zero in the child and
equal to the child's process identifier or PID in the parent.
Using the returned PID, the two processes can see which
one is the parent process and which one is the child process."
-------
so, if you ask the child for its id it would return 0,
but it you ask the parent, that started that child,
the parent would return, a non 0, PID value?
Jorgen Grahn
2020-09-21 19:14:36 UTC
Permalink
Post by G G
from book: operating systems design and implementation
The fork() manual page tells you the same thing.
Post by G G
"The fork call returns a value, which is zero in the child and
equal to the child's process identifier or PID in the parent.
Using the returned PID, the two processes can see which
one is the parent process and which one is the child process."
-------
so, if you ask the child for its id it would return 0,
but it you ask the parent, that started that child,
the parent would return, a non 0, PID value?
You don't really go around asking processes questions, so it's easier
to think of what the two processes see.

int n = fork();

The child will see 0. The parent will see the child's pid, 4711 or
whatever positive value. Or fork() will fail and the single process
will see -1.

/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Scott Lurndal
2020-09-21 19:49:58 UTC
Permalink
Post by Jorgen Grahn
Post by G G
from book: operating systems design and implementation
The fork() manual page tells you the same thing.
Post by G G
"The fork call returns a value, which is zero in the child and
equal to the child's process identifier or PID in the parent.
Using the returned PID, the two processes can see which
one is the parent process and which one is the child process."
-------
so, if you ask the child for its id it would return 0,
but it you ask the parent, that started that child,
the parent would return, a non 0, PID value?
You don't really go around asking processes questions, so it's easier
to think of what the two processes see.
int n = fork();
The child will see 0. The parent will see the child's pid, 4711 or
whatever positive value. Or fork() will fail and the single process
will see -1.
In sixth edition Unix, there was a comment in the code that sets
the fork(2) return value (in a rather complicated way so that
the return in the child picks up a different return value from
the return in the parent):

"You are not expected to understand this".
Keith Thompson
2020-09-21 20:40:30 UTC
Permalink
Post by Scott Lurndal
Post by Jorgen Grahn
Post by G G
from book: operating systems design and implementation
The fork() manual page tells you the same thing.
Post by G G
"The fork call returns a value, which is zero in the child and
equal to the child's process identifier or PID in the parent.
Using the returned PID, the two processes can see which
one is the parent process and which one is the child process."
-------
so, if you ask the child for its id it would return 0,
but it you ask the parent, that started that child,
the parent would return, a non 0, PID value?
You don't really go around asking processes questions, so it's easier
to think of what the two processes see.
int n = fork();
The child will see 0. The parent will see the child's pid, 4711 or
whatever positive value. Or fork() will fail and the single process
will see -1.
In sixth edition Unix, there was a comment in the code that sets
the fork(2) return value (in a rather complicated way so that
the return in the child picks up a different return value from
"You are not expected to understand this".
That infamous comment isn't in the fork() implementation, it's in the
swtch() function:

/*
* This routine is called to reschedule the CPU.
* if the calling process is not in RUN state,
* arrangements for it to restart must have
* been made elsewhere, usually by calling via sleep.
*/
swtch()
{
[...]
/*
* If the new process paused because it was
* swapped out, set the stack level to the last call
* to savu(u_ssav). This means that the return
* which is executed immediately after the call to aretu
* actually returns from the last routine which did
* the savu.
*
* You are not expected to understand this.
*/
if(rp->p_flag&SSWAP) {
rp->p_flag =& ~SSWAP;
aretu(u.u_ssav);
}
/*
* The value returned here has many subtle implications.
* See the newproc comments.
*/
return(1);
}

Source:
https://github.com/dspinellis/unix-history-repo
tag Research-V6
usr/sys/ken/slp.c

Dennis Ritchie's own comment on this:
It’s often quoted as a slur on the quantity or quality of
the comments in the Bell Labs research releases of Unix. Not
an unfair observation in general, I fear, but in this case
unjustified.
[...]
So we tried to explain what was going on. "You are not expected
to understand this" was intended as a remark in the spirit of
"This won’t be on the exam," rather than as an impudent
challenge.

More commentary here:
https://thenewstack.io/not-expected-understand-explainer/
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+***@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
Keith Thompson
2020-09-21 20:48:02 UTC
Permalink
Keith Thompson <Keith.S.Thompson+***@gmail.com> writes:
[...]
Post by Keith Thompson
* You are not expected to understand this.
*/
if(rp->p_flag&SSWAP) {
rp->p_flag =& ~SSWAP;
aretu(u.u_ssav);
}
[...]

Speaking of not understanding this, "=&" is the old spelling of the
"&=" compound assignment operator. It was obsolete by the time K&R1
(Kernighan & Ritchie, "The C Programming Language", 1st Edition)
was published in 1978.

In ancient C, "x=-3" meant "x = x - 3". Because this was a source
of bugs, where the author meant "x = -3", the syntax was changed
some time between 1975 and 1978.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+***@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
Jorgen Grahn
2020-09-22 05:39:39 UTC
Permalink
Post by Keith Thompson
Post by Scott Lurndal
Post by Jorgen Grahn
Post by G G
from book: operating systems design and implementation
The fork() manual page tells you the same thing.
Post by G G
"The fork call returns a value, which is zero in the child and
equal to the child's process identifier or PID in the parent.
Using the returned PID, the two processes can see which
one is the parent process and which one is the child process."
-------
so, if you ask the child for its id it would return 0,
but it you ask the parent, that started that child,
the parent would return, a non 0, PID value?
You don't really go around asking processes questions, so it's easier
to think of what the two processes see.
int n = fork();
The child will see 0. The parent will see the child's pid, 4711 or
whatever positive value. Or fork() will fail and the single process
will see -1.
In sixth edition Unix, there was a comment in the code that sets
the fork(2) return value (in a rather complicated way so that
the return in the child picks up a different return value from
"You are not expected to understand this".
That infamous comment isn't in the fork() implementation, it's in the
And in either case, it doesn't affect the OP. As a user of fork(),
you /are/ expected to understand its interface.

/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Loading...