Mixing
Why is vfork() intended to be used when the child process calls exec() or exit() immediately after creation?
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
Operating System Concepts and APUE say
With vfork(), the parent process
is suspended, and the child process uses the address space of the parent.
Because vfork() does not use copy-on-write, if the child process changes
any pages of the parent’s address space, the altered pages will be visible to the
parent once it resumes. Therefore, vfork() must be used with caution to ensure
that the child process does not modify the address space of the parent.
vfork()
is intended to be used when the child process calls exec() or exit() immediately after
creation.
How shall I understand the last sentence?
When a child process created by vfork() calls exec(), doesn't exec() modify the address space of the parent process, by loading the new program?
When a child process created by vfork() calls exit(), does exit() not modify the address space of the parent process when terminating the child?
Thanks.
linux process exec exit vfork
edited 59 mins ago
Stephen Kitt
150k23333401
asked 1 hour ago
Tim
24k67233419
add a comment |Â
up vote
1
down vote
favorite
Operating System Concepts and APUE say
With vfork(), the parent process
is suspended, and the child process uses the address space of the parent.
Because vfork() does not use copy-on-write, if the child process changes
any pages of the parent’s address space, the altered pages will be visible to the
parent once it resumes. Therefore, vfork() must be used with caution to ensure
that the child process does not modify the address space of the parent.
vfork()
is intended to be used when the child process calls exec() or exit() immediately after
creation.
How shall I understand the last sentence?
When a child process created by vfork() calls exec(), doesn't exec() modify the address space of the parent process, by loading the new program?
When a child process created by vfork() calls exit(), does exit() not modify the address space of the parent process when terminating the child?
Thanks.
linux process exec exit vfork
edited 59 mins ago
Stephen Kitt
150k23333401
asked 1 hour ago
Tim
24k67233419
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
Operating System Concepts and APUE say
With vfork(), the parent process
is suspended, and the child process uses the address space of the parent.
Because vfork() does not use copy-on-write, if the child process changes
any pages of the parent’s address space, the altered pages will be visible to the
parent once it resumes. Therefore, vfork() must be used with caution to ensure
that the child process does not modify the address space of the parent.
vfork()
is intended to be used when the child process calls exec() or exit() immediately after
creation.
How shall I understand the last sentence?
When a child process created by vfork() calls exec(), doesn't exec() modify the address space of the parent process, by loading the new program?
When a child process created by vfork() calls exit(), does exit() not modify the address space of the parent process when terminating the child?
Thanks.
linux process exec exit vfork
edited 59 mins ago
Stephen Kitt
150k23333401
asked 1 hour ago
Tim
24k67233419
Operating System Concepts and APUE say
With vfork(), the parent process
is suspended, and the child process uses the address space of the parent.
Because vfork() does not use copy-on-write, if the child process changes
any pages of the parent’s address space, the altered pages will be visible to the
parent once it resumes. Therefore, vfork() must be used with caution to ensure
that the child process does not modify the address space of the parent.
vfork()
is intended to be used when the child process calls exec() or exit() immediately after
creation.
How shall I understand the last sentence?
When a child process created by vfork() calls exec(), doesn't exec() modify the address space of the parent process, by loading the new program?
When a child process created by vfork() calls exit(), does exit() not modify the address space of the parent process when terminating the child?
Thanks.
linux process exec exit vfork
linux process exec exit vfork
edited 59 mins ago
Stephen Kitt
150k23333401
asked 1 hour ago
Tim
24k67233419
edited 59 mins ago
Stephen Kitt
150k23333401
asked 1 hour ago
Tim
24k67233419
edited 59 mins ago
Stephen Kitt
150k23333401
edited 59 mins ago
Stephen Kitt
150k23333401
edited 59 mins ago
Stephen Kitt
150k23333401
150k23333401
asked 1 hour ago
Tim
24k67233419
asked 1 hour ago
Tim
24k67233419
asked 1 hour ago
Tim
24k67233419
24k67233419
add a comment |Â
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
4
down vote
When a child process created by
vfork()callsexec(), doesn'texec()modify the address space of the parent process, by loading the new program?
No, exec() provides a new address space for the new program; it doesn’t modify the parent address space. See for example the discussion of the exec functions in POSIX, and the Linux execve manpage.
When a child process created by vfork() calls exit(), does exit() not modify the address space of the parent process when terminating the child?
Plain exit() might – it runs exit hooks installed by the running program (including its libraries). vfork() is more restrictive; thus, on Linux, it mandates the use of _exit() which doesn’t call the C library’s clean-up functions.
vfork turned out to be quite difficult to get right; it’s been removed in current versions of the POSIX standard, and posix_spawn() should be used instead.
The Linux manpage linked above provides more context:
However, in the bad old days a
fork(2)
would require making a complete copy of the caller's data space,
often needlessly, since usually immediately afterward anexec(3)is
done. Thus, for greater efficiency, BSD introduced thevfork()
system call, which did not fully copy the address space of the parent
process, but borrowed the parent's memory and thread of control until
a call toexecve(2)or an exit occurred. The parent process was
suspended while the child was using its resources. The use of
vfork()was tricky: for example, not modifying data in the parent
process depended on knowing which variables were held in a register.
edited 37 mins ago
Johan Myréen
7,08111423
answered 59 mins ago
Stephen Kitt
150k23333401
Thanks. "exec() provides a new address space for the new program;" Is the normal behavior of exec() to load a program into the address space of the process? I didn't find in the two links where it creates a new address space either normally or particularly for vfork().
– Tim
54 mins ago
It’s not spelled out in as many words (it’s really an implementation detail) — but “This causes the program that is currently being run by the calling process to be replaced with a new program, with newly initialized stack, heap, and (initialized and uninitialized) data segments.†means that the new process is separate from its parent.
– Stephen Kitt
51 mins ago
Does the quote mean that execve() run by a vforked child doesn't modify the address space of the parent process, and when the parent resumes running, the parent can continue to use the original stack, heap, and (initialized and uninitialized) data segments?
– Tim
36 mins ago
See my answer:exec*()does not modify the address space, it rather creates a new one.
– schily
30 mins ago
add a comment |Â
up vote
3
down vote
When you call vfork(), a new process is created and that new process borrows the process image of the parent process with the exception of the stack. The child process is given an own new stack star however does not allow to return from the function that called vfork().
While the child is running, the parent process is blocked, as the child borrowed the address space of the parent.
Regardless of what you do, everything that just accesses the stack modifies only the private stack of the child. If you however modify global data, this modifies the common data and thus also affects the parent.
Things that modify global data are e.g.:
calling malloc() or free()
using stdio
modifying signal settings
modifying variables that are not local to the function that called
vfork()....
Once you call _exit() (important, never call exit()), the child is terminated and control is given back to the parent.
If you call any function from the exec*() family, a new address space is created with new program code, new data and a new stack. Once this is ready, the child no longer borrows the address space from the child, but uses an own address space.
The control is given back to the parent, as it's address space is no longer in use by another process.
Important: On Linux, there is no real vfork() implementation. Linux rather implements vfork() based on the Copy on Write fork() concept introduced by SunOS-4.0 in 1988. In order to make users believe that they use vfork(), Linux just sets up shared data and suspends the parent while the child did not call _exit() or one of the exec*() functions.
Linux therefore does not benefit from the fact that a real vfork() does not need to set up an address space description for the child in the kernel. This results in a vfork() that is not faster than fork(). On systems that implement a real vfork(), it is typically 3x faster than fork() and affects the performance of shells that use vfork() - ksh93, the recent Bourne Shell and csh.
The reason why you should never call exit() from the vfork()ed child is that exit() flushes stdio in case there is unflushed data from the time before calling vfork(). This could cause strange results.
BTW: posix_spawn() is implemented on top of vfork(), so vfork() is not going to be removed from the OS.
answered 31 mins ago
schily
9,67731537
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
When a child process created by
vfork()callsexec(), doesn'texec()modify the address space of the parent process, by loading the new program?
No, exec() provides a new address space for the new program; it doesn’t modify the parent address space. See for example the discussion of the exec functions in POSIX, and the Linux execve manpage.
When a child process created by vfork() calls exit(), does exit() not modify the address space of the parent process when terminating the child?
Plain exit() might – it runs exit hooks installed by the running program (including its libraries). vfork() is more restrictive; thus, on Linux, it mandates the use of _exit() which doesn’t call the C library’s clean-up functions.
vfork turned out to be quite difficult to get right; it’s been removed in current versions of the POSIX standard, and posix_spawn() should be used instead.
The Linux manpage linked above provides more context:
However, in the bad old days a
fork(2)
would require making a complete copy of the caller's data space,
often needlessly, since usually immediately afterward anexec(3)is
done. Thus, for greater efficiency, BSD introduced thevfork()
system call, which did not fully copy the address space of the parent
process, but borrowed the parent's memory and thread of control until
a call toexecve(2)or an exit occurred. The parent process was
suspended while the child was using its resources. The use of
vfork()was tricky: for example, not modifying data in the parent
process depended on knowing which variables were held in a register.
edited 37 mins ago
Johan Myréen
7,08111423
answered 59 mins ago
Stephen Kitt
150k23333401
Thanks. "exec() provides a new address space for the new program;" Is the normal behavior of exec() to load a program into the address space of the process? I didn't find in the two links where it creates a new address space either normally or particularly for vfork().
– Tim
54 mins ago
It’s not spelled out in as many words (it’s really an implementation detail) — but “This causes the program that is currently being run by the calling process to be replaced with a new program, with newly initialized stack, heap, and (initialized and uninitialized) data segments.†means that the new process is separate from its parent.
– Stephen Kitt
51 mins ago
Does the quote mean that execve() run by a vforked child doesn't modify the address space of the parent process, and when the parent resumes running, the parent can continue to use the original stack, heap, and (initialized and uninitialized) data segments?
– Tim
36 mins ago
See my answer:exec*()does not modify the address space, it rather creates a new one.
– schily
30 mins ago
add a comment |Â
up vote
4
down vote
When a child process created by
vfork()callsexec(), doesn'texec()modify the address space of the parent process, by loading the new program?
No, exec() provides a new address space for the new program; it doesn’t modify the parent address space. See for example the discussion of the exec functions in POSIX, and the Linux execve manpage.
When a child process created by vfork() calls exit(), does exit() not modify the address space of the parent process when terminating the child?
Plain exit() might – it runs exit hooks installed by the running program (including its libraries). vfork() is more restrictive; thus, on Linux, it mandates the use of _exit() which doesn’t call the C library’s clean-up functions.
vfork turned out to be quite difficult to get right; it’s been removed in current versions of the POSIX standard, and posix_spawn() should be used instead.
The Linux manpage linked above provides more context:
However, in the bad old days a
fork(2)
would require making a complete copy of the caller's data space,
often needlessly, since usually immediately afterward anexec(3)is
done. Thus, for greater efficiency, BSD introduced thevfork()
system call, which did not fully copy the address space of the parent
process, but borrowed the parent's memory and thread of control until
a call toexecve(2)or an exit occurred. The parent process was
suspended while the child was using its resources. The use of
vfork()was tricky: for example, not modifying data in the parent
process depended on knowing which variables were held in a register.
edited 37 mins ago
Johan Myréen
7,08111423
answered 59 mins ago
Stephen Kitt
150k23333401
Thanks. "exec() provides a new address space for the new program;" Is the normal behavior of exec() to load a program into the address space of the process? I didn't find in the two links where it creates a new address space either normally or particularly for vfork().
– Tim
54 mins ago
It’s not spelled out in as many words (it’s really an implementation detail) — but “This causes the program that is currently being run by the calling process to be replaced with a new program, with newly initialized stack, heap, and (initialized and uninitialized) data segments.†means that the new process is separate from its parent.
– Stephen Kitt
51 mins ago
Does the quote mean that execve() run by a vforked child doesn't modify the address space of the parent process, and when the parent resumes running, the parent can continue to use the original stack, heap, and (initialized and uninitialized) data segments?
– Tim
36 mins ago
See my answer:exec*()does not modify the address space, it rather creates a new one.
– schily
30 mins ago
add a comment |Â
up vote
4
down vote
up vote
4
down vote
When a child process created by
vfork()callsexec(), doesn'texec()modify the address space of the parent process, by loading the new program?
No, exec() provides a new address space for the new program; it doesn’t modify the parent address space. See for example the discussion of the exec functions in POSIX, and the Linux execve manpage.
When a child process created by vfork() calls exit(), does exit() not modify the address space of the parent process when terminating the child?
Plain exit() might – it runs exit hooks installed by the running program (including its libraries). vfork() is more restrictive; thus, on Linux, it mandates the use of _exit() which doesn’t call the C library’s clean-up functions.
vfork turned out to be quite difficult to get right; it’s been removed in current versions of the POSIX standard, and posix_spawn() should be used instead.
The Linux manpage linked above provides more context:
However, in the bad old days a
fork(2)
would require making a complete copy of the caller's data space,
often needlessly, since usually immediately afterward anexec(3)is
done. Thus, for greater efficiency, BSD introduced thevfork()
system call, which did not fully copy the address space of the parent
process, but borrowed the parent's memory and thread of control until
a call toexecve(2)or an exit occurred. The parent process was
suspended while the child was using its resources. The use of
vfork()was tricky: for example, not modifying data in the parent
process depended on knowing which variables were held in a register.
edited 37 mins ago
Johan Myréen
7,08111423
answered 59 mins ago
Stephen Kitt
150k23333401
When a child process created by
vfork()callsexec(), doesn'texec()modify the address space of the parent process, by loading the new program?
No, exec() provides a new address space for the new program; it doesn’t modify the parent address space. See for example the discussion of the exec functions in POSIX, and the Linux execve manpage.
When a child process created by vfork() calls exit(), does exit() not modify the address space of the parent process when terminating the child?
Plain exit() might – it runs exit hooks installed by the running program (including its libraries). vfork() is more restrictive; thus, on Linux, it mandates the use of _exit() which doesn’t call the C library’s clean-up functions.
vfork turned out to be quite difficult to get right; it’s been removed in current versions of the POSIX standard, and posix_spawn() should be used instead.
The Linux manpage linked above provides more context:
However, in the bad old days a
fork(2)
would require making a complete copy of the caller's data space,
often needlessly, since usually immediately afterward anexec(3)is
done. Thus, for greater efficiency, BSD introduced thevfork()
system call, which did not fully copy the address space of the parent
process, but borrowed the parent's memory and thread of control until
a call toexecve(2)or an exit occurred. The parent process was
suspended while the child was using its resources. The use of
vfork()was tricky: for example, not modifying data in the parent
process depended on knowing which variables were held in a register.
edited 37 mins ago
Johan Myréen
7,08111423
answered 59 mins ago
Stephen Kitt
150k23333401
edited 37 mins ago
Johan Myréen
7,08111423
edited 37 mins ago
Johan Myréen
7,08111423
edited 37 mins ago
Johan Myréen
7,08111423
7,08111423
answered 59 mins ago
Stephen Kitt
150k23333401
answered 59 mins ago
Stephen Kitt
150k23333401
answered 59 mins ago
Stephen Kitt
150k23333401
150k23333401
Thanks. "exec() provides a new address space for the new program;" Is the normal behavior of exec() to load a program into the address space of the process? I didn't find in the two links where it creates a new address space either normally or particularly for vfork().
– Tim
54 mins ago
It’s not spelled out in as many words (it’s really an implementation detail) — but “This causes the program that is currently being run by the calling process to be replaced with a new program, with newly initialized stack, heap, and (initialized and uninitialized) data segments.†means that the new process is separate from its parent.
– Stephen Kitt
51 mins ago
Does the quote mean that execve() run by a vforked child doesn't modify the address space of the parent process, and when the parent resumes running, the parent can continue to use the original stack, heap, and (initialized and uninitialized) data segments?
– Tim
36 mins ago
See my answer:exec*()does not modify the address space, it rather creates a new one.
– schily
30 mins ago
add a comment |Â
Thanks. "exec() provides a new address space for the new program;" Is the normal behavior of exec() to load a program into the address space of the process? I didn't find in the two links where it creates a new address space either normally or particularly for vfork().
– Tim
54 mins ago
It’s not spelled out in as many words (it’s really an implementation detail) — but “This causes the program that is currently being run by the calling process to be replaced with a new program, with newly initialized stack, heap, and (initialized and uninitialized) data segments.†means that the new process is separate from its parent.
– Stephen Kitt
51 mins ago
Does the quote mean that execve() run by a vforked child doesn't modify the address space of the parent process, and when the parent resumes running, the parent can continue to use the original stack, heap, and (initialized and uninitialized) data segments?
– Tim
36 mins ago
See my answer:exec*()does not modify the address space, it rather creates a new one.
– schily
30 mins ago
Thanks. "exec() provides a new address space for the new program;" Is the normal behavior of exec() to load a program into the address space of the process? I didn't find in the two links where it creates a new address space either normally or particularly for vfork().
– Tim
54 mins ago
Thanks. "exec() provides a new address space for the new program;" Is the normal behavior of exec() to load a program into the address space of the process? I didn't find in the two links where it creates a new address space either normally or particularly for vfork().
– Tim
54 mins ago
It’s not spelled out in as many words (it’s really an implementation detail) — but “This causes the program that is currently being run by the calling process to be replaced with a new program, with newly initialized stack, heap, and (initialized and uninitialized) data segments.†means that the new process is separate from its parent.
– Stephen Kitt
51 mins ago
It’s not spelled out in as many words (it’s really an implementation detail) — but “This causes the program that is currently being run by the calling process to be replaced with a new program, with newly initialized stack, heap, and (initialized and uninitialized) data segments.†means that the new process is separate from its parent.
– Stephen Kitt
51 mins ago
Does the quote mean that execve() run by a vforked child doesn't modify the address space of the parent process, and when the parent resumes running, the parent can continue to use the original stack, heap, and (initialized and uninitialized) data segments?
– Tim
36 mins ago
Does the quote mean that execve() run by a vforked child doesn't modify the address space of the parent process, and when the parent resumes running, the parent can continue to use the original stack, heap, and (initialized and uninitialized) data segments?
– Tim
36 mins ago
See my answer:
exec*() does not modify the address space, it rather creates a new one.– schily
30 mins ago
See my answer:
exec*() does not modify the address space, it rather creates a new one.– schily
30 mins ago
add a comment |Â
up vote
3
down vote
When you call vfork(), a new process is created and that new process borrows the process image of the parent process with the exception of the stack. The child process is given an own new stack star however does not allow to return from the function that called vfork().
While the child is running, the parent process is blocked, as the child borrowed the address space of the parent.
Regardless of what you do, everything that just accesses the stack modifies only the private stack of the child. If you however modify global data, this modifies the common data and thus also affects the parent.
Things that modify global data are e.g.:
calling malloc() or free()
using stdio
modifying signal settings
modifying variables that are not local to the function that called
vfork()....
Once you call _exit() (important, never call exit()), the child is terminated and control is given back to the parent.
If you call any function from the exec*() family, a new address space is created with new program code, new data and a new stack. Once this is ready, the child no longer borrows the address space from the child, but uses an own address space.
The control is given back to the parent, as it's address space is no longer in use by another process.
Important: On Linux, there is no real vfork() implementation. Linux rather implements vfork() based on the Copy on Write fork() concept introduced by SunOS-4.0 in 1988. In order to make users believe that they use vfork(), Linux just sets up shared data and suspends the parent while the child did not call _exit() or one of the exec*() functions.
Linux therefore does not benefit from the fact that a real vfork() does not need to set up an address space description for the child in the kernel. This results in a vfork() that is not faster than fork(). On systems that implement a real vfork(), it is typically 3x faster than fork() and affects the performance of shells that use vfork() - ksh93, the recent Bourne Shell and csh.
The reason why you should never call exit() from the vfork()ed child is that exit() flushes stdio in case there is unflushed data from the time before calling vfork(). This could cause strange results.
BTW: posix_spawn() is implemented on top of vfork(), so vfork() is not going to be removed from the OS.
answered 31 mins ago
schily
9,67731537
add a comment |Â
up vote
3
down vote
When you call vfork(), a new process is created and that new process borrows the process image of the parent process with the exception of the stack. The child process is given an own new stack star however does not allow to return from the function that called vfork().
While the child is running, the parent process is blocked, as the child borrowed the address space of the parent.
Regardless of what you do, everything that just accesses the stack modifies only the private stack of the child. If you however modify global data, this modifies the common data and thus also affects the parent.
Things that modify global data are e.g.:
calling malloc() or free()
using stdio
modifying signal settings
modifying variables that are not local to the function that called
vfork()....
Once you call _exit() (important, never call exit()), the child is terminated and control is given back to the parent.
If you call any function from the exec*() family, a new address space is created with new program code, new data and a new stack. Once this is ready, the child no longer borrows the address space from the child, but uses an own address space.
The control is given back to the parent, as it's address space is no longer in use by another process.
Important: On Linux, there is no real vfork() implementation. Linux rather implements vfork() based on the Copy on Write fork() concept introduced by SunOS-4.0 in 1988. In order to make users believe that they use vfork(), Linux just sets up shared data and suspends the parent while the child did not call _exit() or one of the exec*() functions.
Linux therefore does not benefit from the fact that a real vfork() does not need to set up an address space description for the child in the kernel. This results in a vfork() that is not faster than fork(). On systems that implement a real vfork(), it is typically 3x faster than fork() and affects the performance of shells that use vfork() - ksh93, the recent Bourne Shell and csh.
The reason why you should never call exit() from the vfork()ed child is that exit() flushes stdio in case there is unflushed data from the time before calling vfork(). This could cause strange results.
BTW: posix_spawn() is implemented on top of vfork(), so vfork() is not going to be removed from the OS.
answered 31 mins ago
schily
9,67731537
add a comment |Â
up vote
3
down vote
up vote
3
down vote
When you call vfork(), a new process is created and that new process borrows the process image of the parent process with the exception of the stack. The child process is given an own new stack star however does not allow to return from the function that called vfork().
While the child is running, the parent process is blocked, as the child borrowed the address space of the parent.
Regardless of what you do, everything that just accesses the stack modifies only the private stack of the child. If you however modify global data, this modifies the common data and thus also affects the parent.
Things that modify global data are e.g.:
calling malloc() or free()
using stdio
modifying signal settings
modifying variables that are not local to the function that called
vfork()....
Once you call _exit() (important, never call exit()), the child is terminated and control is given back to the parent.
If you call any function from the exec*() family, a new address space is created with new program code, new data and a new stack. Once this is ready, the child no longer borrows the address space from the child, but uses an own address space.
The control is given back to the parent, as it's address space is no longer in use by another process.
Important: On Linux, there is no real vfork() implementation. Linux rather implements vfork() based on the Copy on Write fork() concept introduced by SunOS-4.0 in 1988. In order to make users believe that they use vfork(), Linux just sets up shared data and suspends the parent while the child did not call _exit() or one of the exec*() functions.
Linux therefore does not benefit from the fact that a real vfork() does not need to set up an address space description for the child in the kernel. This results in a vfork() that is not faster than fork(). On systems that implement a real vfork(), it is typically 3x faster than fork() and affects the performance of shells that use vfork() - ksh93, the recent Bourne Shell and csh.
The reason why you should never call exit() from the vfork()ed child is that exit() flushes stdio in case there is unflushed data from the time before calling vfork(). This could cause strange results.
BTW: posix_spawn() is implemented on top of vfork(), so vfork() is not going to be removed from the OS.
answered 31 mins ago
schily
9,67731537
When you call vfork(), a new process is created and that new process borrows the process image of the parent process with the exception of the stack. The child process is given an own new stack star however does not allow to return from the function that called vfork().
While the child is running, the parent process is blocked, as the child borrowed the address space of the parent.
Regardless of what you do, everything that just accesses the stack modifies only the private stack of the child. If you however modify global data, this modifies the common data and thus also affects the parent.
Things that modify global data are e.g.:
calling malloc() or free()
using stdio
modifying signal settings
modifying variables that are not local to the function that called
vfork()....
Once you call _exit() (important, never call exit()), the child is terminated and control is given back to the parent.
If you call any function from the exec*() family, a new address space is created with new program code, new data and a new stack. Once this is ready, the child no longer borrows the address space from the child, but uses an own address space.
The control is given back to the parent, as it's address space is no longer in use by another process.
Important: On Linux, there is no real vfork() implementation. Linux rather implements vfork() based on the Copy on Write fork() concept introduced by SunOS-4.0 in 1988. In order to make users believe that they use vfork(), Linux just sets up shared data and suspends the parent while the child did not call _exit() or one of the exec*() functions.
Linux therefore does not benefit from the fact that a real vfork() does not need to set up an address space description for the child in the kernel. This results in a vfork() that is not faster than fork(). On systems that implement a real vfork(), it is typically 3x faster than fork() and affects the performance of shells that use vfork() - ksh93, the recent Bourne Shell and csh.
The reason why you should never call exit() from the vfork()ed child is that exit() flushes stdio in case there is unflushed data from the time before calling vfork(). This could cause strange results.
BTW: posix_spawn() is implemented on top of vfork(), so vfork() is not going to be removed from the OS.
answered 31 mins ago
schily
9,67731537
edited 26 mins ago
answered 31 mins ago
schily
9,67731537
answered 31 mins ago
schily
9,67731537
answered 31 mins ago
schily
9,67731537
9,67731537
add a comment |Â
add a comment |Â
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
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f475609%2fwhy-is-vfork-intended-to-be-used-when-the-child-process-calls-exec-or-exit%23new-answer', 'question_page');
);
Post as a guest
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
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
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