This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 18/09/18 00:20, Rich Felker wrote:
Yes, that is true. My understanding is that vfork was intended only as a fast way of doing fork/exec sequence.The historical contract of vfork is that you can basically do nothing after it returns in the child except for exec or _exit
One thing to note is that vfork is completely unsafe to use as documented if any signal handlers are installed, unless you block all signals before calling vfork, in which case the exec'd process will inherit a fully-blocked signal mask which is probably not what you want. Otherwise signal handlers may wrongly run in the child that's sharing memory with the parent.
You're saying that kernel will deliver a signal to child pid when it was parent pid that was signalled. Can that really happen?
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |