When vfork is called is parent process really suspended?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
3
down vote

favorite












As much as I know when vfork is called child process uses the same address space as that of the parent and any changes made by the child process in parents variables are reflected onto parents process. My questions are:



  • When child process is spawned is parent process suspended?

  • If yes why?

  • They can run in parallel (like Threads)? After all both threads and process call the same clone() function.

Also after bit of research and Goggling I found out that the parent process is not really suspended but the calling thread is suspended. Even if this is the case when child process does an exit() or exec(). How does parent process know that the child has exited? And what will happen if we return from a child process?`










share|improve this question



























    up vote
    3
    down vote

    favorite












    As much as I know when vfork is called child process uses the same address space as that of the parent and any changes made by the child process in parents variables are reflected onto parents process. My questions are:



    • When child process is spawned is parent process suspended?

    • If yes why?

    • They can run in parallel (like Threads)? After all both threads and process call the same clone() function.

    Also after bit of research and Goggling I found out that the parent process is not really suspended but the calling thread is suspended. Even if this is the case when child process does an exit() or exec(). How does parent process know that the child has exited? And what will happen if we return from a child process?`










    share|improve this question

























      up vote
      3
      down vote

      favorite









      up vote
      3
      down vote

      favorite











      As much as I know when vfork is called child process uses the same address space as that of the parent and any changes made by the child process in parents variables are reflected onto parents process. My questions are:



      • When child process is spawned is parent process suspended?

      • If yes why?

      • They can run in parallel (like Threads)? After all both threads and process call the same clone() function.

      Also after bit of research and Goggling I found out that the parent process is not really suspended but the calling thread is suspended. Even if this is the case when child process does an exit() or exec(). How does parent process know that the child has exited? And what will happen if we return from a child process?`










      share|improve this question















      As much as I know when vfork is called child process uses the same address space as that of the parent and any changes made by the child process in parents variables are reflected onto parents process. My questions are:



      • When child process is spawned is parent process suspended?

      • If yes why?

      • They can run in parallel (like Threads)? After all both threads and process call the same clone() function.

      Also after bit of research and Goggling I found out that the parent process is not really suspended but the calling thread is suspended. Even if this is the case when child process does an exit() or exec(). How does parent process know that the child has exited? And what will happen if we return from a child process?`







      process fork






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Jul 23 '13 at 13:10









      Braiam

      22.7k1972133




      22.7k1972133










      asked Jul 23 '13 at 12:24









      Aniket Thakur

      243111




      243111




















          3 Answers
          3






          active

          oldest

          votes

















          up vote
          2
          down vote



          accepted










          Your question is partly based on bad naming convention. A "thread of control" in kernel-speak is a process in user-speak. So when you read that vfork "the calling thread is suspended" think "process" (or "heavyweight thread" if you like) not "thread" as in "multi-threaded process".



          • So yes, the parent process is suspended.

          vfork semantics were defined for the very common case where a process (the shell most often) would fork, mess with some file descriptors, and then exec another process in place. The kernel folks realized they could save a huge amount of page copying overhead if they skipped the copy since the exec was just going to throw those copied pages away. A vforked child does have its own file descriptor table in the kernel, so manipulating that doesn't affect the parent process, keeping the semantics of fork unchanged.



          • Why? Because fork/exec was common, expensive, and wasteful

          Given the more accurate definition of "kernel thread of control", the answer to can they run in parallel is clearly



          • No, the parent will be blocked by the kernel until the child exits or execs

          How does the parent know the child has exited?



          • It doesn't, the kernel knows and keeps the parent from getting any CPU at all until the child has gone away.

          As for the last question, I would suspect that the kernel would detect the child stack operations involved in a return and signal the child with an uncatchable signal or just kill it, but I don't know the details.






          share|improve this answer




















          • are you sure about this? I've written quite simple program (yet too long to paste here) which creates 40 pthreads, performs vfork in each of them, and exec if pid=0 in each child process, performing 2x sleep(1) between vfork and exec, and logging each step. I can see in logs, that all vforks are batched together, then come all "midsteps" and then all execs. The only explanation I see to this is that other pthreads are not paused when vfork is called.
            – qbolec
            Oct 23 '14 at 10:57










          • Yes, it is correct. Your test code contains actions that you don't fully understand, in particular how sleep() is implemented.
            – msw
            Oct 23 '14 at 16:41

















          up vote
          1
          down vote













          I am not a linux programmer, but facing the same question today, I've made a following test:



          #include<unistd.h>
          #include<signal.h>
          #include<errno.h>
          #include<fcntl.h>
          #include<cassert>
          #include<cstring>
          #include<string>
          #include<algorithm>
          #include<vector>
          #include<map>
          #include<set>
          #include<iostream>
          #include<fstream>
          #include<sstream>
          #include<list>
          using namespace std;
          int single_talk(int thread_id)
          fprintf(stderr,"thread %d before fork @%dn",thread_id,time(0));
          int pid=vfork();
          if(-1==pid)
          cerr << "failed to fork: " << strerror(errno) << endl;
          _exit(-3);//serious problem, can not proceed

          sleep(1);
          fprintf(stderr,"thread %d fork returned %d @%dn",thread_id,pid,time(0));
          if(pid)//"CPP"
          fprintf(stderr,"thread %d in parentn",thread_id);
          else//"PHP"
          sleep(1);
          fprintf(stderr,"thread %d in child @%dn",thread_id,time(0));
          if(-1 == execlp("/bin/ls","ls",(char*)NULL))
          cerr << "failed to execl php : " << strerror(errno) << endl;
          _exit(-4);//serious problem, can not proceed



          void * talker(void * id)
          single_talk(*(int*)id);
          return NULL;

          int main()
          signal(SIGPIPE,SIG_IGN);
          signal(SIGCHLD,SIG_IGN);
          const int thread_count = 44;
          pthread_t thread[thread_count];
          int thread_id[thread_count];
          int err;
          for(size_t i=0;i<thread_count;++i)
          thread_id[i]=i;
          if((err = pthread_create(thread+i,NULL,talker,thread_id+i)))
          cerr << "failed to create pthread: " << strerror(err) << endl;
          exit(-7);


          for(size_t i=0;i<thread_count;++i)
          if((err = pthread_join(thread[i],NULL)))
          cerr << "failed to join pthread: " << strerror(err) << endl;
          exit(-17);





          I've compiled it with g++ -pthread -o repro repro.cpp and run with ./repro.
          What I see in the output is that everything happens simultanously in rounds : first all pthreads run vfork, then all wait a second, then "wake up" in the child process reality, then all childs run exec(), then finally all parents wake up.



          To me, this proves that if one pthread calls a vfork it does not suspend the other pthreads - if it did, then they wouldn't be able to call vfork()s until the exec() is called.






          share|improve this answer




















          • What this demonstrates is that if you write to the parent dataspace prior to vforking, then all the threads will have the same value for for that variable. It also shows that you don't understand how sleep() is implemented. Finally, this should be its own question because it is a question, not an answer.
            – msw
            Oct 23 '14 at 16:38






          • 1




            Which variable do you mean in particular? Could you please run this code and explain to me why all these pthreads perform actions while they should be suspended? Is it because sleep unsuspends them? I don't think that using sleep is crucial for this demo, because we see this behaviour in production, while we do not do sleep's there :/
            – qbolec
            Oct 23 '14 at 18:49






          • 1




            Please present this as a new question and I'll be happy to. I'm not trying to be obnoxious, but them's the StackOverflow rules (and they make sense for a site that wants to be pure Q&A)
            – msw
            Oct 23 '14 at 19:44










          • @msw thanks, here is the question: unix.stackexchange.com/questions/163947/pthreads-and-vfork
            – qbolec
            Oct 24 '14 at 7:56

















          up vote
          0
          down vote














          When child process is spawned is parent process suspended?




          Yes.




          If yes why?




          Because the parent and child are sharing address space. In particular, address space of the stack. If the parent tried to continue on it would likely call another function and trash the child process's call stack. So it does not run until exec() or _exit()




          They can run in parallel (like Threads)? After all both threads and process call the same clone() function.




          Indeed. Only the calling thread is suspended. See above.




          How does parent process know that the child has exited?




          It calls wait4(). But rather, you ask how the parent knows to continue. It doesn't. The kernel makes it runnable again when either of the two defined events occur.




          And what will happen if we return from a child process?




          vfork() returns into a freed stack frame, and the next return; is a fast path to undefined behavior.






          share|improve this answer




















            Your Answer







            StackExchange.ready(function()
            var channelOptions =
            tags: "".split(" "),
            id: "106"
            ;
            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',
            convertImagesToLinks: false,
            noModals: false,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            );



            );













             

            draft saved


            draft discarded


















            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f84101%2fwhen-vfork-is-called-is-parent-process-really-suspended%23new-answer', 'question_page');

            );

            Post as a guest






























            3 Answers
            3






            active

            oldest

            votes








            3 Answers
            3






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes








            up vote
            2
            down vote



            accepted










            Your question is partly based on bad naming convention. A "thread of control" in kernel-speak is a process in user-speak. So when you read that vfork "the calling thread is suspended" think "process" (or "heavyweight thread" if you like) not "thread" as in "multi-threaded process".



            • So yes, the parent process is suspended.

            vfork semantics were defined for the very common case where a process (the shell most often) would fork, mess with some file descriptors, and then exec another process in place. The kernel folks realized they could save a huge amount of page copying overhead if they skipped the copy since the exec was just going to throw those copied pages away. A vforked child does have its own file descriptor table in the kernel, so manipulating that doesn't affect the parent process, keeping the semantics of fork unchanged.



            • Why? Because fork/exec was common, expensive, and wasteful

            Given the more accurate definition of "kernel thread of control", the answer to can they run in parallel is clearly



            • No, the parent will be blocked by the kernel until the child exits or execs

            How does the parent know the child has exited?



            • It doesn't, the kernel knows and keeps the parent from getting any CPU at all until the child has gone away.

            As for the last question, I would suspect that the kernel would detect the child stack operations involved in a return and signal the child with an uncatchable signal or just kill it, but I don't know the details.






            share|improve this answer




















            • are you sure about this? I've written quite simple program (yet too long to paste here) which creates 40 pthreads, performs vfork in each of them, and exec if pid=0 in each child process, performing 2x sleep(1) between vfork and exec, and logging each step. I can see in logs, that all vforks are batched together, then come all "midsteps" and then all execs. The only explanation I see to this is that other pthreads are not paused when vfork is called.
              – qbolec
              Oct 23 '14 at 10:57










            • Yes, it is correct. Your test code contains actions that you don't fully understand, in particular how sleep() is implemented.
              – msw
              Oct 23 '14 at 16:41














            up vote
            2
            down vote



            accepted










            Your question is partly based on bad naming convention. A "thread of control" in kernel-speak is a process in user-speak. So when you read that vfork "the calling thread is suspended" think "process" (or "heavyweight thread" if you like) not "thread" as in "multi-threaded process".



            • So yes, the parent process is suspended.

            vfork semantics were defined for the very common case where a process (the shell most often) would fork, mess with some file descriptors, and then exec another process in place. The kernel folks realized they could save a huge amount of page copying overhead if they skipped the copy since the exec was just going to throw those copied pages away. A vforked child does have its own file descriptor table in the kernel, so manipulating that doesn't affect the parent process, keeping the semantics of fork unchanged.



            • Why? Because fork/exec was common, expensive, and wasteful

            Given the more accurate definition of "kernel thread of control", the answer to can they run in parallel is clearly



            • No, the parent will be blocked by the kernel until the child exits or execs

            How does the parent know the child has exited?



            • It doesn't, the kernel knows and keeps the parent from getting any CPU at all until the child has gone away.

            As for the last question, I would suspect that the kernel would detect the child stack operations involved in a return and signal the child with an uncatchable signal or just kill it, but I don't know the details.






            share|improve this answer




















            • are you sure about this? I've written quite simple program (yet too long to paste here) which creates 40 pthreads, performs vfork in each of them, and exec if pid=0 in each child process, performing 2x sleep(1) between vfork and exec, and logging each step. I can see in logs, that all vforks are batched together, then come all "midsteps" and then all execs. The only explanation I see to this is that other pthreads are not paused when vfork is called.
              – qbolec
              Oct 23 '14 at 10:57










            • Yes, it is correct. Your test code contains actions that you don't fully understand, in particular how sleep() is implemented.
              – msw
              Oct 23 '14 at 16:41












            up vote
            2
            down vote



            accepted







            up vote
            2
            down vote



            accepted






            Your question is partly based on bad naming convention. A "thread of control" in kernel-speak is a process in user-speak. So when you read that vfork "the calling thread is suspended" think "process" (or "heavyweight thread" if you like) not "thread" as in "multi-threaded process".



            • So yes, the parent process is suspended.

            vfork semantics were defined for the very common case where a process (the shell most often) would fork, mess with some file descriptors, and then exec another process in place. The kernel folks realized they could save a huge amount of page copying overhead if they skipped the copy since the exec was just going to throw those copied pages away. A vforked child does have its own file descriptor table in the kernel, so manipulating that doesn't affect the parent process, keeping the semantics of fork unchanged.



            • Why? Because fork/exec was common, expensive, and wasteful

            Given the more accurate definition of "kernel thread of control", the answer to can they run in parallel is clearly



            • No, the parent will be blocked by the kernel until the child exits or execs

            How does the parent know the child has exited?



            • It doesn't, the kernel knows and keeps the parent from getting any CPU at all until the child has gone away.

            As for the last question, I would suspect that the kernel would detect the child stack operations involved in a return and signal the child with an uncatchable signal or just kill it, but I don't know the details.






            share|improve this answer












            Your question is partly based on bad naming convention. A "thread of control" in kernel-speak is a process in user-speak. So when you read that vfork "the calling thread is suspended" think "process" (or "heavyweight thread" if you like) not "thread" as in "multi-threaded process".



            • So yes, the parent process is suspended.

            vfork semantics were defined for the very common case where a process (the shell most often) would fork, mess with some file descriptors, and then exec another process in place. The kernel folks realized they could save a huge amount of page copying overhead if they skipped the copy since the exec was just going to throw those copied pages away. A vforked child does have its own file descriptor table in the kernel, so manipulating that doesn't affect the parent process, keeping the semantics of fork unchanged.



            • Why? Because fork/exec was common, expensive, and wasteful

            Given the more accurate definition of "kernel thread of control", the answer to can they run in parallel is clearly



            • No, the parent will be blocked by the kernel until the child exits or execs

            How does the parent know the child has exited?



            • It doesn't, the kernel knows and keeps the parent from getting any CPU at all until the child has gone away.

            As for the last question, I would suspect that the kernel would detect the child stack operations involved in a return and signal the child with an uncatchable signal or just kill it, but I don't know the details.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Jul 23 '13 at 13:48









            msw

            8,7752236




            8,7752236











            • are you sure about this? I've written quite simple program (yet too long to paste here) which creates 40 pthreads, performs vfork in each of them, and exec if pid=0 in each child process, performing 2x sleep(1) between vfork and exec, and logging each step. I can see in logs, that all vforks are batched together, then come all "midsteps" and then all execs. The only explanation I see to this is that other pthreads are not paused when vfork is called.
              – qbolec
              Oct 23 '14 at 10:57










            • Yes, it is correct. Your test code contains actions that you don't fully understand, in particular how sleep() is implemented.
              – msw
              Oct 23 '14 at 16:41
















            • are you sure about this? I've written quite simple program (yet too long to paste here) which creates 40 pthreads, performs vfork in each of them, and exec if pid=0 in each child process, performing 2x sleep(1) between vfork and exec, and logging each step. I can see in logs, that all vforks are batched together, then come all "midsteps" and then all execs. The only explanation I see to this is that other pthreads are not paused when vfork is called.
              – qbolec
              Oct 23 '14 at 10:57










            • Yes, it is correct. Your test code contains actions that you don't fully understand, in particular how sleep() is implemented.
              – msw
              Oct 23 '14 at 16:41















            are you sure about this? I've written quite simple program (yet too long to paste here) which creates 40 pthreads, performs vfork in each of them, and exec if pid=0 in each child process, performing 2x sleep(1) between vfork and exec, and logging each step. I can see in logs, that all vforks are batched together, then come all "midsteps" and then all execs. The only explanation I see to this is that other pthreads are not paused when vfork is called.
            – qbolec
            Oct 23 '14 at 10:57




            are you sure about this? I've written quite simple program (yet too long to paste here) which creates 40 pthreads, performs vfork in each of them, and exec if pid=0 in each child process, performing 2x sleep(1) between vfork and exec, and logging each step. I can see in logs, that all vforks are batched together, then come all "midsteps" and then all execs. The only explanation I see to this is that other pthreads are not paused when vfork is called.
            – qbolec
            Oct 23 '14 at 10:57












            Yes, it is correct. Your test code contains actions that you don't fully understand, in particular how sleep() is implemented.
            – msw
            Oct 23 '14 at 16:41




            Yes, it is correct. Your test code contains actions that you don't fully understand, in particular how sleep() is implemented.
            – msw
            Oct 23 '14 at 16:41












            up vote
            1
            down vote













            I am not a linux programmer, but facing the same question today, I've made a following test:



            #include<unistd.h>
            #include<signal.h>
            #include<errno.h>
            #include<fcntl.h>
            #include<cassert>
            #include<cstring>
            #include<string>
            #include<algorithm>
            #include<vector>
            #include<map>
            #include<set>
            #include<iostream>
            #include<fstream>
            #include<sstream>
            #include<list>
            using namespace std;
            int single_talk(int thread_id)
            fprintf(stderr,"thread %d before fork @%dn",thread_id,time(0));
            int pid=vfork();
            if(-1==pid)
            cerr << "failed to fork: " << strerror(errno) << endl;
            _exit(-3);//serious problem, can not proceed

            sleep(1);
            fprintf(stderr,"thread %d fork returned %d @%dn",thread_id,pid,time(0));
            if(pid)//"CPP"
            fprintf(stderr,"thread %d in parentn",thread_id);
            else//"PHP"
            sleep(1);
            fprintf(stderr,"thread %d in child @%dn",thread_id,time(0));
            if(-1 == execlp("/bin/ls","ls",(char*)NULL))
            cerr << "failed to execl php : " << strerror(errno) << endl;
            _exit(-4);//serious problem, can not proceed



            void * talker(void * id)
            single_talk(*(int*)id);
            return NULL;

            int main()
            signal(SIGPIPE,SIG_IGN);
            signal(SIGCHLD,SIG_IGN);
            const int thread_count = 44;
            pthread_t thread[thread_count];
            int thread_id[thread_count];
            int err;
            for(size_t i=0;i<thread_count;++i)
            thread_id[i]=i;
            if((err = pthread_create(thread+i,NULL,talker,thread_id+i)))
            cerr << "failed to create pthread: " << strerror(err) << endl;
            exit(-7);


            for(size_t i=0;i<thread_count;++i)
            if((err = pthread_join(thread[i],NULL)))
            cerr << "failed to join pthread: " << strerror(err) << endl;
            exit(-17);





            I've compiled it with g++ -pthread -o repro repro.cpp and run with ./repro.
            What I see in the output is that everything happens simultanously in rounds : first all pthreads run vfork, then all wait a second, then "wake up" in the child process reality, then all childs run exec(), then finally all parents wake up.



            To me, this proves that if one pthread calls a vfork it does not suspend the other pthreads - if it did, then they wouldn't be able to call vfork()s until the exec() is called.






            share|improve this answer




















            • What this demonstrates is that if you write to the parent dataspace prior to vforking, then all the threads will have the same value for for that variable. It also shows that you don't understand how sleep() is implemented. Finally, this should be its own question because it is a question, not an answer.
              – msw
              Oct 23 '14 at 16:38






            • 1




              Which variable do you mean in particular? Could you please run this code and explain to me why all these pthreads perform actions while they should be suspended? Is it because sleep unsuspends them? I don't think that using sleep is crucial for this demo, because we see this behaviour in production, while we do not do sleep's there :/
              – qbolec
              Oct 23 '14 at 18:49






            • 1




              Please present this as a new question and I'll be happy to. I'm not trying to be obnoxious, but them's the StackOverflow rules (and they make sense for a site that wants to be pure Q&A)
              – msw
              Oct 23 '14 at 19:44










            • @msw thanks, here is the question: unix.stackexchange.com/questions/163947/pthreads-and-vfork
              – qbolec
              Oct 24 '14 at 7:56














            up vote
            1
            down vote













            I am not a linux programmer, but facing the same question today, I've made a following test:



            #include<unistd.h>
            #include<signal.h>
            #include<errno.h>
            #include<fcntl.h>
            #include<cassert>
            #include<cstring>
            #include<string>
            #include<algorithm>
            #include<vector>
            #include<map>
            #include<set>
            #include<iostream>
            #include<fstream>
            #include<sstream>
            #include<list>
            using namespace std;
            int single_talk(int thread_id)
            fprintf(stderr,"thread %d before fork @%dn",thread_id,time(0));
            int pid=vfork();
            if(-1==pid)
            cerr << "failed to fork: " << strerror(errno) << endl;
            _exit(-3);//serious problem, can not proceed

            sleep(1);
            fprintf(stderr,"thread %d fork returned %d @%dn",thread_id,pid,time(0));
            if(pid)//"CPP"
            fprintf(stderr,"thread %d in parentn",thread_id);
            else//"PHP"
            sleep(1);
            fprintf(stderr,"thread %d in child @%dn",thread_id,time(0));
            if(-1 == execlp("/bin/ls","ls",(char*)NULL))
            cerr << "failed to execl php : " << strerror(errno) << endl;
            _exit(-4);//serious problem, can not proceed



            void * talker(void * id)
            single_talk(*(int*)id);
            return NULL;

            int main()
            signal(SIGPIPE,SIG_IGN);
            signal(SIGCHLD,SIG_IGN);
            const int thread_count = 44;
            pthread_t thread[thread_count];
            int thread_id[thread_count];
            int err;
            for(size_t i=0;i<thread_count;++i)
            thread_id[i]=i;
            if((err = pthread_create(thread+i,NULL,talker,thread_id+i)))
            cerr << "failed to create pthread: " << strerror(err) << endl;
            exit(-7);


            for(size_t i=0;i<thread_count;++i)
            if((err = pthread_join(thread[i],NULL)))
            cerr << "failed to join pthread: " << strerror(err) << endl;
            exit(-17);





            I've compiled it with g++ -pthread -o repro repro.cpp and run with ./repro.
            What I see in the output is that everything happens simultanously in rounds : first all pthreads run vfork, then all wait a second, then "wake up" in the child process reality, then all childs run exec(), then finally all parents wake up.



            To me, this proves that if one pthread calls a vfork it does not suspend the other pthreads - if it did, then they wouldn't be able to call vfork()s until the exec() is called.






            share|improve this answer




















            • What this demonstrates is that if you write to the parent dataspace prior to vforking, then all the threads will have the same value for for that variable. It also shows that you don't understand how sleep() is implemented. Finally, this should be its own question because it is a question, not an answer.
              – msw
              Oct 23 '14 at 16:38






            • 1




              Which variable do you mean in particular? Could you please run this code and explain to me why all these pthreads perform actions while they should be suspended? Is it because sleep unsuspends them? I don't think that using sleep is crucial for this demo, because we see this behaviour in production, while we do not do sleep's there :/
              – qbolec
              Oct 23 '14 at 18:49






            • 1




              Please present this as a new question and I'll be happy to. I'm not trying to be obnoxious, but them's the StackOverflow rules (and they make sense for a site that wants to be pure Q&A)
              – msw
              Oct 23 '14 at 19:44










            • @msw thanks, here is the question: unix.stackexchange.com/questions/163947/pthreads-and-vfork
              – qbolec
              Oct 24 '14 at 7:56












            up vote
            1
            down vote










            up vote
            1
            down vote









            I am not a linux programmer, but facing the same question today, I've made a following test:



            #include<unistd.h>
            #include<signal.h>
            #include<errno.h>
            #include<fcntl.h>
            #include<cassert>
            #include<cstring>
            #include<string>
            #include<algorithm>
            #include<vector>
            #include<map>
            #include<set>
            #include<iostream>
            #include<fstream>
            #include<sstream>
            #include<list>
            using namespace std;
            int single_talk(int thread_id)
            fprintf(stderr,"thread %d before fork @%dn",thread_id,time(0));
            int pid=vfork();
            if(-1==pid)
            cerr << "failed to fork: " << strerror(errno) << endl;
            _exit(-3);//serious problem, can not proceed

            sleep(1);
            fprintf(stderr,"thread %d fork returned %d @%dn",thread_id,pid,time(0));
            if(pid)//"CPP"
            fprintf(stderr,"thread %d in parentn",thread_id);
            else//"PHP"
            sleep(1);
            fprintf(stderr,"thread %d in child @%dn",thread_id,time(0));
            if(-1 == execlp("/bin/ls","ls",(char*)NULL))
            cerr << "failed to execl php : " << strerror(errno) << endl;
            _exit(-4);//serious problem, can not proceed



            void * talker(void * id)
            single_talk(*(int*)id);
            return NULL;

            int main()
            signal(SIGPIPE,SIG_IGN);
            signal(SIGCHLD,SIG_IGN);
            const int thread_count = 44;
            pthread_t thread[thread_count];
            int thread_id[thread_count];
            int err;
            for(size_t i=0;i<thread_count;++i)
            thread_id[i]=i;
            if((err = pthread_create(thread+i,NULL,talker,thread_id+i)))
            cerr << "failed to create pthread: " << strerror(err) << endl;
            exit(-7);


            for(size_t i=0;i<thread_count;++i)
            if((err = pthread_join(thread[i],NULL)))
            cerr << "failed to join pthread: " << strerror(err) << endl;
            exit(-17);





            I've compiled it with g++ -pthread -o repro repro.cpp and run with ./repro.
            What I see in the output is that everything happens simultanously in rounds : first all pthreads run vfork, then all wait a second, then "wake up" in the child process reality, then all childs run exec(), then finally all parents wake up.



            To me, this proves that if one pthread calls a vfork it does not suspend the other pthreads - if it did, then they wouldn't be able to call vfork()s until the exec() is called.






            share|improve this answer












            I am not a linux programmer, but facing the same question today, I've made a following test:



            #include<unistd.h>
            #include<signal.h>
            #include<errno.h>
            #include<fcntl.h>
            #include<cassert>
            #include<cstring>
            #include<string>
            #include<algorithm>
            #include<vector>
            #include<map>
            #include<set>
            #include<iostream>
            #include<fstream>
            #include<sstream>
            #include<list>
            using namespace std;
            int single_talk(int thread_id)
            fprintf(stderr,"thread %d before fork @%dn",thread_id,time(0));
            int pid=vfork();
            if(-1==pid)
            cerr << "failed to fork: " << strerror(errno) << endl;
            _exit(-3);//serious problem, can not proceed

            sleep(1);
            fprintf(stderr,"thread %d fork returned %d @%dn",thread_id,pid,time(0));
            if(pid)//"CPP"
            fprintf(stderr,"thread %d in parentn",thread_id);
            else//"PHP"
            sleep(1);
            fprintf(stderr,"thread %d in child @%dn",thread_id,time(0));
            if(-1 == execlp("/bin/ls","ls",(char*)NULL))
            cerr << "failed to execl php : " << strerror(errno) << endl;
            _exit(-4);//serious problem, can not proceed



            void * talker(void * id)
            single_talk(*(int*)id);
            return NULL;

            int main()
            signal(SIGPIPE,SIG_IGN);
            signal(SIGCHLD,SIG_IGN);
            const int thread_count = 44;
            pthread_t thread[thread_count];
            int thread_id[thread_count];
            int err;
            for(size_t i=0;i<thread_count;++i)
            thread_id[i]=i;
            if((err = pthread_create(thread+i,NULL,talker,thread_id+i)))
            cerr << "failed to create pthread: " << strerror(err) << endl;
            exit(-7);


            for(size_t i=0;i<thread_count;++i)
            if((err = pthread_join(thread[i],NULL)))
            cerr << "failed to join pthread: " << strerror(err) << endl;
            exit(-17);





            I've compiled it with g++ -pthread -o repro repro.cpp and run with ./repro.
            What I see in the output is that everything happens simultanously in rounds : first all pthreads run vfork, then all wait a second, then "wake up" in the child process reality, then all childs run exec(), then finally all parents wake up.



            To me, this proves that if one pthread calls a vfork it does not suspend the other pthreads - if it did, then they wouldn't be able to call vfork()s until the exec() is called.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Oct 23 '14 at 11:09









            qbolec

            1585




            1585











            • What this demonstrates is that if you write to the parent dataspace prior to vforking, then all the threads will have the same value for for that variable. It also shows that you don't understand how sleep() is implemented. Finally, this should be its own question because it is a question, not an answer.
              – msw
              Oct 23 '14 at 16:38






            • 1




              Which variable do you mean in particular? Could you please run this code and explain to me why all these pthreads perform actions while they should be suspended? Is it because sleep unsuspends them? I don't think that using sleep is crucial for this demo, because we see this behaviour in production, while we do not do sleep's there :/
              – qbolec
              Oct 23 '14 at 18:49






            • 1




              Please present this as a new question and I'll be happy to. I'm not trying to be obnoxious, but them's the StackOverflow rules (and they make sense for a site that wants to be pure Q&A)
              – msw
              Oct 23 '14 at 19:44










            • @msw thanks, here is the question: unix.stackexchange.com/questions/163947/pthreads-and-vfork
              – qbolec
              Oct 24 '14 at 7:56
















            • What this demonstrates is that if you write to the parent dataspace prior to vforking, then all the threads will have the same value for for that variable. It also shows that you don't understand how sleep() is implemented. Finally, this should be its own question because it is a question, not an answer.
              – msw
              Oct 23 '14 at 16:38






            • 1




              Which variable do you mean in particular? Could you please run this code and explain to me why all these pthreads perform actions while they should be suspended? Is it because sleep unsuspends them? I don't think that using sleep is crucial for this demo, because we see this behaviour in production, while we do not do sleep's there :/
              – qbolec
              Oct 23 '14 at 18:49






            • 1




              Please present this as a new question and I'll be happy to. I'm not trying to be obnoxious, but them's the StackOverflow rules (and they make sense for a site that wants to be pure Q&A)
              – msw
              Oct 23 '14 at 19:44










            • @msw thanks, here is the question: unix.stackexchange.com/questions/163947/pthreads-and-vfork
              – qbolec
              Oct 24 '14 at 7:56















            What this demonstrates is that if you write to the parent dataspace prior to vforking, then all the threads will have the same value for for that variable. It also shows that you don't understand how sleep() is implemented. Finally, this should be its own question because it is a question, not an answer.
            – msw
            Oct 23 '14 at 16:38




            What this demonstrates is that if you write to the parent dataspace prior to vforking, then all the threads will have the same value for for that variable. It also shows that you don't understand how sleep() is implemented. Finally, this should be its own question because it is a question, not an answer.
            – msw
            Oct 23 '14 at 16:38




            1




            1




            Which variable do you mean in particular? Could you please run this code and explain to me why all these pthreads perform actions while they should be suspended? Is it because sleep unsuspends them? I don't think that using sleep is crucial for this demo, because we see this behaviour in production, while we do not do sleep's there :/
            – qbolec
            Oct 23 '14 at 18:49




            Which variable do you mean in particular? Could you please run this code and explain to me why all these pthreads perform actions while they should be suspended? Is it because sleep unsuspends them? I don't think that using sleep is crucial for this demo, because we see this behaviour in production, while we do not do sleep's there :/
            – qbolec
            Oct 23 '14 at 18:49




            1




            1




            Please present this as a new question and I'll be happy to. I'm not trying to be obnoxious, but them's the StackOverflow rules (and they make sense for a site that wants to be pure Q&A)
            – msw
            Oct 23 '14 at 19:44




            Please present this as a new question and I'll be happy to. I'm not trying to be obnoxious, but them's the StackOverflow rules (and they make sense for a site that wants to be pure Q&A)
            – msw
            Oct 23 '14 at 19:44












            @msw thanks, here is the question: unix.stackexchange.com/questions/163947/pthreads-and-vfork
            – qbolec
            Oct 24 '14 at 7:56




            @msw thanks, here is the question: unix.stackexchange.com/questions/163947/pthreads-and-vfork
            – qbolec
            Oct 24 '14 at 7:56










            up vote
            0
            down vote














            When child process is spawned is parent process suspended?




            Yes.




            If yes why?




            Because the parent and child are sharing address space. In particular, address space of the stack. If the parent tried to continue on it would likely call another function and trash the child process's call stack. So it does not run until exec() or _exit()




            They can run in parallel (like Threads)? After all both threads and process call the same clone() function.




            Indeed. Only the calling thread is suspended. See above.




            How does parent process know that the child has exited?




            It calls wait4(). But rather, you ask how the parent knows to continue. It doesn't. The kernel makes it runnable again when either of the two defined events occur.




            And what will happen if we return from a child process?




            vfork() returns into a freed stack frame, and the next return; is a fast path to undefined behavior.






            share|improve this answer
























              up vote
              0
              down vote














              When child process is spawned is parent process suspended?




              Yes.




              If yes why?




              Because the parent and child are sharing address space. In particular, address space of the stack. If the parent tried to continue on it would likely call another function and trash the child process's call stack. So it does not run until exec() or _exit()




              They can run in parallel (like Threads)? After all both threads and process call the same clone() function.




              Indeed. Only the calling thread is suspended. See above.




              How does parent process know that the child has exited?




              It calls wait4(). But rather, you ask how the parent knows to continue. It doesn't. The kernel makes it runnable again when either of the two defined events occur.




              And what will happen if we return from a child process?




              vfork() returns into a freed stack frame, and the next return; is a fast path to undefined behavior.






              share|improve this answer






















                up vote
                0
                down vote










                up vote
                0
                down vote










                When child process is spawned is parent process suspended?




                Yes.




                If yes why?




                Because the parent and child are sharing address space. In particular, address space of the stack. If the parent tried to continue on it would likely call another function and trash the child process's call stack. So it does not run until exec() or _exit()




                They can run in parallel (like Threads)? After all both threads and process call the same clone() function.




                Indeed. Only the calling thread is suspended. See above.




                How does parent process know that the child has exited?




                It calls wait4(). But rather, you ask how the parent knows to continue. It doesn't. The kernel makes it runnable again when either of the two defined events occur.




                And what will happen if we return from a child process?




                vfork() returns into a freed stack frame, and the next return; is a fast path to undefined behavior.






                share|improve this answer













                When child process is spawned is parent process suspended?




                Yes.




                If yes why?




                Because the parent and child are sharing address space. In particular, address space of the stack. If the parent tried to continue on it would likely call another function and trash the child process's call stack. So it does not run until exec() or _exit()




                They can run in parallel (like Threads)? After all both threads and process call the same clone() function.




                Indeed. Only the calling thread is suspended. See above.




                How does parent process know that the child has exited?




                It calls wait4(). But rather, you ask how the parent knows to continue. It doesn't. The kernel makes it runnable again when either of the two defined events occur.




                And what will happen if we return from a child process?




                vfork() returns into a freed stack frame, and the next return; is a fast path to undefined behavior.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered 10 mins ago









                Joshua

                1,029711




                1,029711



























                     

                    draft saved


                    draft discarded















































                     


                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function ()
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f84101%2fwhen-vfork-is-called-is-parent-process-really-suspended%23new-answer', 'question_page');

                    );

                    Post as a guest













































































                    Popular posts from this blog

                    Peggy Mitchell

                    Palaiologos

                    The Forum (Inglewood, California)