Mixing
python os.fork child process ID is not continuous
3
I am trying on os.fork function using CPython 3.7.2
Here is the example
def main():
data = 222
childPid = os.fork()
if childPid == -1:
print('error on fork child')
elif childPid == 0:
data *= 3
else:
time.sleep(3)
print("PID=%d data=%d" % (os.getpid(), data))
When I use C language, I always get 2 continuous PID for parent and child.
However in python, I always get PID which are not continuous( for example here I got 21475 and 21442).
PID=21475 data=666
PID=21442 data=222
Don't understand how it behave not same.
python
asked Jan 3 at 1:03
CSJCSJ
1,10121125
|
show 2 more comments
3
I am trying on os.fork function using CPython 3.7.2
Here is the example
def main():
data = 222
childPid = os.fork()
if childPid == -1:
print('error on fork child')
elif childPid == 0:
data *= 3
else:
time.sleep(3)
print("PID=%d data=%d" % (os.getpid(), data))
When I use C language, I always get 2 continuous PID for parent and child.
However in python, I always get PID which are not continuous( for example here I got 21475 and 21442).
PID=21475 data=666
PID=21442 data=222
Don't understand how it behave not same.
python
asked Jan 3 at 1:03
CSJCSJ
1,10121125
1
Why would it matter?
– Daniel Roseman
Jan 3 at 1:05
just curious, cause since it is CPython, if we use the same system call in low level, the OS usually allocate next free PID for child which I read from book, so I am wondering why they behave not same
– CSJ
Jan 3 at 1:07
It's not guaranteed to be consecutive in any language -- not in C either. Writing code that depends on behavior that isn't a documented guarantee is a path to pain and suffering; building your mental models on such observations, likewise.
– Charles Duffy
Jan 3 at 1:09
3
I'm voting to close this question as off-topic because Stack Overflow requires that questions be "based on actual problems that you face", and this is a matter of curiosity: The behavior at hand is explicitly and intentionally implementation-defined and subject to change at any time for any reason or no reason at all.
– Charles Duffy
Jan 3 at 1:15
It's the same system call, yes, but in C there's less likelihood of the thread being preempted and another process being created in the meantime.
– Daniel Roseman
Jan 3 at 1:19
|
show 2 more comments
3
3
3
I am trying on os.fork function using CPython 3.7.2
Here is the example
def main():
data = 222
childPid = os.fork()
if childPid == -1:
print('error on fork child')
elif childPid == 0:
data *= 3
else:
time.sleep(3)
print("PID=%d data=%d" % (os.getpid(), data))
When I use C language, I always get 2 continuous PID for parent and child.
However in python, I always get PID which are not continuous( for example here I got 21475 and 21442).
PID=21475 data=666
PID=21442 data=222
Don't understand how it behave not same.
python
asked Jan 3 at 1:03
CSJCSJ
1,10121125
I am trying on os.fork function using CPython 3.7.2
Here is the example
def main():
data = 222
childPid = os.fork()
if childPid == -1:
print('error on fork child')
elif childPid == 0:
data *= 3
else:
time.sleep(3)
print("PID=%d data=%d" % (os.getpid(), data))
When I use C language, I always get 2 continuous PID for parent and child.
However in python, I always get PID which are not continuous( for example here I got 21475 and 21442).
PID=21475 data=666
PID=21442 data=222
Don't understand how it behave not same.
python
python
asked Jan 3 at 1:03
CSJCSJ
1,10121125
asked Jan 3 at 1:03
CSJCSJ
1,10121125
asked Jan 3 at 1:03
CSJCSJ
1,10121125
asked Jan 3 at 1:03
CSJCSJ
1,10121125
asked Jan 3 at 1:03
CSJCSJ
1,10121125
1,10121125
1
Why would it matter?
– Daniel Roseman
Jan 3 at 1:05
just curious, cause since it is CPython, if we use the same system call in low level, the OS usually allocate next free PID for child which I read from book, so I am wondering why they behave not same
– CSJ
Jan 3 at 1:07
It's not guaranteed to be consecutive in any language -- not in C either. Writing code that depends on behavior that isn't a documented guarantee is a path to pain and suffering; building your mental models on such observations, likewise.
– Charles Duffy
Jan 3 at 1:09
3
I'm voting to close this question as off-topic because Stack Overflow requires that questions be "based on actual problems that you face", and this is a matter of curiosity: The behavior at hand is explicitly and intentionally implementation-defined and subject to change at any time for any reason or no reason at all.
– Charles Duffy
Jan 3 at 1:15
It's the same system call, yes, but in C there's less likelihood of the thread being preempted and another process being created in the meantime.
– Daniel Roseman
Jan 3 at 1:19
|
show 2 more comments
1
Why would it matter?
– Daniel Roseman
Jan 3 at 1:05
just curious, cause since it is CPython, if we use the same system call in low level, the OS usually allocate next free PID for child which I read from book, so I am wondering why they behave not same
– CSJ
Jan 3 at 1:07
It's not guaranteed to be consecutive in any language -- not in C either. Writing code that depends on behavior that isn't a documented guarantee is a path to pain and suffering; building your mental models on such observations, likewise.
– Charles Duffy
Jan 3 at 1:09
3
I'm voting to close this question as off-topic because Stack Overflow requires that questions be "based on actual problems that you face", and this is a matter of curiosity: The behavior at hand is explicitly and intentionally implementation-defined and subject to change at any time for any reason or no reason at all.
– Charles Duffy
Jan 3 at 1:15
It's the same system call, yes, but in C there's less likelihood of the thread being preempted and another process being created in the meantime.
– Daniel Roseman
Jan 3 at 1:19
1
1
Why would it matter?
– Daniel Roseman
Jan 3 at 1:05
Why would it matter?
– Daniel Roseman
Jan 3 at 1:05
just curious, cause since it is CPython, if we use the same system call in low level, the OS usually allocate next free PID for child which I read from book, so I am wondering why they behave not same
– CSJ
Jan 3 at 1:07
just curious, cause since it is CPython, if we use the same system call in low level, the OS usually allocate next free PID for child which I read from book, so I am wondering why they behave not same
– CSJ
Jan 3 at 1:07
It's not guaranteed to be consecutive in any language -- not in C either. Writing code that depends on behavior that isn't a documented guarantee is a path to pain and suffering; building your mental models on such observations, likewise.
– Charles Duffy
Jan 3 at 1:09
It's not guaranteed to be consecutive in any language -- not in C either. Writing code that depends on behavior that isn't a documented guarantee is a path to pain and suffering; building your mental models on such observations, likewise.
– Charles Duffy
Jan 3 at 1:09
3
3
I'm voting to close this question as off-topic because Stack Overflow requires that questions be "based on actual problems that you face", and this is a matter of curiosity: The behavior at hand is explicitly and intentionally implementation-defined and subject to change at any time for any reason or no reason at all.
– Charles Duffy
Jan 3 at 1:15
I'm voting to close this question as off-topic because Stack Overflow requires that questions be "based on actual problems that you face", and this is a matter of curiosity: The behavior at hand is explicitly and intentionally implementation-defined and subject to change at any time for any reason or no reason at all.
– Charles Duffy
Jan 3 at 1:15
It's the same system call, yes, but in C there's less likelihood of the thread being preempted and another process being created in the meantime.
– Daniel Roseman
Jan 3 at 1:19
It's the same system call, yes, but in C there's less likelihood of the thread being preempted and another process being created in the meantime.
– Daniel Roseman
Jan 3 at 1:19
|
show 2 more comments
1 Answer
1
active
oldest
votes
5
PIDs are not guaranteed to be consecutive, although they typically are (on Linux). If a PID is already in use, it will be skipped.
If you saw consecutive PIDs when testing C code, it's because you happened to not come across an in-use PID. There should be no difference in behavior between fork() in C and os.fork() in Python.
answered Jan 3 at 1:04
Jonathon ReinhartJonathon Reinhart
92.5k21168237
To add to this -- PIDS are generated sequentially. However, there are numerous situations where a PID won't be sequential (such as an existing PID already in existence with the next PID value in the sequence). In that situation, the kernel will create a PID with the next available value in the sequence. One should not expect PIDS to be sequential when forking processes. The only guarantee is that all PIDs are unique (there are never two PIDs given the same number).
– Jason Baumgartner
Jan 3 at 1:07
4
What you describe is accurate for Linux, but not for some BSDs where PIDs are randomly assigned.
– Jonathon Reinhart
Jan 3 at 1:09
I am curious why thenext availablealways not consecutive when I use python, looks like 100% chance. and my working system is not that busy
– CSJ
Jan 3 at 1:10
1
Usestraceorsysdigor somesuch to look at the actual syscalls. If there is any actual difference in what the runtimes are doing, it will necessarily be exposed at the syscall layer. And assysdiggives you a full-system view of all your processes at any point in time, its logs include tracking which PIDs are at use at the time of eachfork().
– Charles Duffy
Jan 3 at 1:10
Jonathon Reinhart -- good point. That's an important detail to know.
– Jason Baumgartner
Jan 3 at 1:11
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54015106%2fpython-os-fork-child-process-id-is-not-continuous%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
5
PIDs are not guaranteed to be consecutive, although they typically are (on Linux). If a PID is already in use, it will be skipped.
If you saw consecutive PIDs when testing C code, it's because you happened to not come across an in-use PID. There should be no difference in behavior between fork() in C and os.fork() in Python.
answered Jan 3 at 1:04
Jonathon ReinhartJonathon Reinhart
92.5k21168237
To add to this -- PIDS are generated sequentially. However, there are numerous situations where a PID won't be sequential (such as an existing PID already in existence with the next PID value in the sequence). In that situation, the kernel will create a PID with the next available value in the sequence. One should not expect PIDS to be sequential when forking processes. The only guarantee is that all PIDs are unique (there are never two PIDs given the same number).
– Jason Baumgartner
Jan 3 at 1:07
4
What you describe is accurate for Linux, but not for some BSDs where PIDs are randomly assigned.
– Jonathon Reinhart
Jan 3 at 1:09
I am curious why thenext availablealways not consecutive when I use python, looks like 100% chance. and my working system is not that busy
– CSJ
Jan 3 at 1:10
1
Usestraceorsysdigor somesuch to look at the actual syscalls. If there is any actual difference in what the runtimes are doing, it will necessarily be exposed at the syscall layer. And assysdiggives you a full-system view of all your processes at any point in time, its logs include tracking which PIDs are at use at the time of eachfork().
– Charles Duffy
Jan 3 at 1:10
Jonathon Reinhart -- good point. That's an important detail to know.
– Jason Baumgartner
Jan 3 at 1:11
add a comment |
5
PIDs are not guaranteed to be consecutive, although they typically are (on Linux). If a PID is already in use, it will be skipped.
If you saw consecutive PIDs when testing C code, it's because you happened to not come across an in-use PID. There should be no difference in behavior between fork() in C and os.fork() in Python.
answered Jan 3 at 1:04
Jonathon ReinhartJonathon Reinhart
92.5k21168237
To add to this -- PIDS are generated sequentially. However, there are numerous situations where a PID won't be sequential (such as an existing PID already in existence with the next PID value in the sequence). In that situation, the kernel will create a PID with the next available value in the sequence. One should not expect PIDS to be sequential when forking processes. The only guarantee is that all PIDs are unique (there are never two PIDs given the same number).
– Jason Baumgartner
Jan 3 at 1:07
4
What you describe is accurate for Linux, but not for some BSDs where PIDs are randomly assigned.
– Jonathon Reinhart
Jan 3 at 1:09
I am curious why thenext availablealways not consecutive when I use python, looks like 100% chance. and my working system is not that busy
– CSJ
Jan 3 at 1:10
1
Usestraceorsysdigor somesuch to look at the actual syscalls. If there is any actual difference in what the runtimes are doing, it will necessarily be exposed at the syscall layer. And assysdiggives you a full-system view of all your processes at any point in time, its logs include tracking which PIDs are at use at the time of eachfork().
– Charles Duffy
Jan 3 at 1:10
Jonathon Reinhart -- good point. That's an important detail to know.
– Jason Baumgartner
Jan 3 at 1:11
add a comment |
5
5
5
PIDs are not guaranteed to be consecutive, although they typically are (on Linux). If a PID is already in use, it will be skipped.
If you saw consecutive PIDs when testing C code, it's because you happened to not come across an in-use PID. There should be no difference in behavior between fork() in C and os.fork() in Python.
answered Jan 3 at 1:04
Jonathon ReinhartJonathon Reinhart
92.5k21168237
PIDs are not guaranteed to be consecutive, although they typically are (on Linux). If a PID is already in use, it will be skipped.
If you saw consecutive PIDs when testing C code, it's because you happened to not come across an in-use PID. There should be no difference in behavior between fork() in C and os.fork() in Python.
answered Jan 3 at 1:04
Jonathon ReinhartJonathon Reinhart
92.5k21168237
edited Jan 3 at 1:08
answered Jan 3 at 1:04
Jonathon ReinhartJonathon Reinhart
92.5k21168237
answered Jan 3 at 1:04
Jonathon ReinhartJonathon Reinhart
92.5k21168237
answered Jan 3 at 1:04
Jonathon ReinhartJonathon Reinhart
92.5k21168237
92.5k21168237
To add to this -- PIDS are generated sequentially. However, there are numerous situations where a PID won't be sequential (such as an existing PID already in existence with the next PID value in the sequence). In that situation, the kernel will create a PID with the next available value in the sequence. One should not expect PIDS to be sequential when forking processes. The only guarantee is that all PIDs are unique (there are never two PIDs given the same number).
– Jason Baumgartner
Jan 3 at 1:07
4
What you describe is accurate for Linux, but not for some BSDs where PIDs are randomly assigned.
– Jonathon Reinhart
Jan 3 at 1:09
I am curious why thenext availablealways not consecutive when I use python, looks like 100% chance. and my working system is not that busy
– CSJ
Jan 3 at 1:10
1
Usestraceorsysdigor somesuch to look at the actual syscalls. If there is any actual difference in what the runtimes are doing, it will necessarily be exposed at the syscall layer. And assysdiggives you a full-system view of all your processes at any point in time, its logs include tracking which PIDs are at use at the time of eachfork().
– Charles Duffy
Jan 3 at 1:10
Jonathon Reinhart -- good point. That's an important detail to know.
– Jason Baumgartner
Jan 3 at 1:11
add a comment |
To add to this -- PIDS are generated sequentially. However, there are numerous situations where a PID won't be sequential (such as an existing PID already in existence with the next PID value in the sequence). In that situation, the kernel will create a PID with the next available value in the sequence. One should not expect PIDS to be sequential when forking processes. The only guarantee is that all PIDs are unique (there are never two PIDs given the same number).
– Jason Baumgartner
Jan 3 at 1:07
4
What you describe is accurate for Linux, but not for some BSDs where PIDs are randomly assigned.
– Jonathon Reinhart
Jan 3 at 1:09
I am curious why thenext availablealways not consecutive when I use python, looks like 100% chance. and my working system is not that busy
– CSJ
Jan 3 at 1:10
1
Usestraceorsysdigor somesuch to look at the actual syscalls. If there is any actual difference in what the runtimes are doing, it will necessarily be exposed at the syscall layer. And assysdiggives you a full-system view of all your processes at any point in time, its logs include tracking which PIDs are at use at the time of eachfork().
– Charles Duffy
Jan 3 at 1:10
Jonathon Reinhart -- good point. That's an important detail to know.
– Jason Baumgartner
Jan 3 at 1:11
To add to this -- PIDS are generated sequentially. However, there are numerous situations where a PID won't be sequential (such as an existing PID already in existence with the next PID value in the sequence). In that situation, the kernel will create a PID with the next available value in the sequence. One should not expect PIDS to be sequential when forking processes. The only guarantee is that all PIDs are unique (there are never two PIDs given the same number).
– Jason Baumgartner
Jan 3 at 1:07
To add to this -- PIDS are generated sequentially. However, there are numerous situations where a PID won't be sequential (such as an existing PID already in existence with the next PID value in the sequence). In that situation, the kernel will create a PID with the next available value in the sequence. One should not expect PIDS to be sequential when forking processes. The only guarantee is that all PIDs are unique (there are never two PIDs given the same number).
– Jason Baumgartner
Jan 3 at 1:07
4
4
What you describe is accurate for Linux, but not for some BSDs where PIDs are randomly assigned.
– Jonathon Reinhart
Jan 3 at 1:09
What you describe is accurate for Linux, but not for some BSDs where PIDs are randomly assigned.
– Jonathon Reinhart
Jan 3 at 1:09
I am curious why the
next available always not consecutive when I use python, looks like 100% chance. and my working system is not that busy– CSJ
Jan 3 at 1:10
I am curious why the
next available always not consecutive when I use python, looks like 100% chance. and my working system is not that busy– CSJ
Jan 3 at 1:10
1
1
Use
strace or sysdig or somesuch to look at the actual syscalls. If there is any actual difference in what the runtimes are doing, it will necessarily be exposed at the syscall layer. And as sysdig gives you a full-system view of all your processes at any point in time, its logs include tracking which PIDs are at use at the time of each fork().– Charles Duffy
Jan 3 at 1:10
Use
strace or sysdig or somesuch to look at the actual syscalls. If there is any actual difference in what the runtimes are doing, it will necessarily be exposed at the syscall layer. And as sysdig gives you a full-system view of all your processes at any point in time, its logs include tracking which PIDs are at use at the time of each fork().– Charles Duffy
Jan 3 at 1:10
Jonathon Reinhart -- good point. That's an important detail to know.
– Jason Baumgartner
Jan 3 at 1:11
Jonathon Reinhart -- good point. That's an important detail to know.
– Jason Baumgartner
Jan 3 at 1:11
add a comment |
draft saved
draft discarded
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54015106%2fpython-os-fork-child-process-id-is-not-continuous%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Why would it matter?
– Daniel Roseman
Jan 3 at 1:05
just curious, cause since it is CPython, if we use the same system call in low level, the OS usually allocate next free PID for child which I read from book, so I am wondering why they behave not same
– CSJ
Jan 3 at 1:07
It's not guaranteed to be consecutive in any language -- not in C either. Writing code that depends on behavior that isn't a documented guarantee is a path to pain and suffering; building your mental models on such observations, likewise.
– Charles Duffy
Jan 3 at 1:09
3
I'm voting to close this question as off-topic because Stack Overflow requires that questions be "based on actual problems that you face", and this is a matter of curiosity: The behavior at hand is explicitly and intentionally implementation-defined and subject to change at any time for any reason or no reason at all.
– Charles Duffy
Jan 3 at 1:15
It's the same system call, yes, but in C there's less likelihood of the thread being preempted and another process being created in the meantime.
– Daniel Roseman
Jan 3 at 1:19