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