home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c++.moderated      Moderated discussion of C++ superhackery      33,346 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 32,356 of 33,346   
   Wil Evers to Joshua Maurice   
   Re: program launcher API for C++?   
   03 Jun 12 16:54:36   
   
   12cc6b3e   
   From: bouncer@dev.null   
      
   Joshua Maurice wrote:   
   > Wil Evers wrote:   
   >> Joshua Maurice wrote:   
   >>   
   >> > The only way to spawn a new process in POSIX is fork().  (Which   
   >> > is "usually" followed quickly thereafter by an exec() in the   
   >> > child.)  You are correct that you cannot use malloc in the child   
   >> > before an exec(). However, you can write the necessary child code   
   >> > without calling malloc nor any other async-signal unsafe   
   >> > function. You can safely use fork() + exec() in a multi-threaded   
   >> > process.   
   >>   
   >> Another issue with calling fork() + exec() from a multi-threaded   
   >> process is that the child may unexpectedly inherit open file   
   >> descriptors.  Depending on what other threads are doing, it can be   
   >> very hard so ensure that all file descriptors that should not be   
   >> inherited have the close-on-exec flag set at the moment one of the   
   >> threads calls fork().   
   >   
   > Indeed. Mentioned it in my first post on the topic.   
      
   You did.  I reacted to your "you can safely use fork() + exec() in a   
   multithreaded process" without remembering your previous posting; I'm   
   sorry about that.  On the other hand, this issue is non-obvious and   
   real, developers should be aware of it, so it doesn't really hurt to   
   mention it twice :-).   
      
   [snip]   
      
   > (As a meager attempt to stay on topic): If C++ were to ever have a   
   > standard process spawning library, or even to anyone from Boost here   
   > listening, could we please have the semantics be to create a fresh   
   > new process, and you have to go out of your way to inherit things to   
   > children, instead of the other way around?   
      
   Well, I can certainly see why it makes sense to inherit (or redirect)   
   the standard input, output and error channels.  The thing I don't   
   understand is why any other descriptor should be inherited.  How is an   
   exec'ed()/CreatedProcess()'ed program even supposed to be aware of any   
   other descriptor?  It seems to me that implicitly passing on any handle   
   other than a standard one is just asking for trouble.   
      
   Regards,   
      
   - Wil   
      
      
   --   
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca