On Mon, Oct 05, 2009 at 10:27:22PM +0200, Corinna Vinschen wrote: >On Oct 5 15:04, Charles Wilson wrote: >> Normally, posix programs should call abort(), exit(), _exit(), kill() -- >> or various pthread functions -- to terminate operation (either their >> own, or that of some other processes/thread). However, there are two >> cases where the win32 ExitProcess and TerminateProcess functions might >> justifiably be called: >> 1) inside cygwin's own process startup/shutdown implementation >> 2) "Native" programs that use the w32api throughout, but are compiled >> using the cygwin compiler (e.g. without -mno-cygwin). [*] >> >> However, the ExitProcess and TerminateProcess functions, when called >> directly, do not allow for the 'exit status' maintained by cygwin to be >> set. This can be a problem when such cygwin applications are exec'ed by >> other cygwin apps: cygwin's code for exec'ing children doesn't ever >> check the value of GetExitCodeProcess as set by these win32 functions, >> if the child application is also a cygwin app. >> >> The attached patch address this problem, by providing two wrappers: >> cygwin_terminate_process <--> TerminateProcess >> cygwin_exit_process <--> ExitProcess > >I have some doubts that we really need such a functionality externally >available, outside of the limited scenario of something like >pseudo-reloc. An API for those knowing what this is about is very >likely sufficient. What about > > cygwin_internal (CW_TERMINATE_PROCESS); > cygwin_internal (CW_EXIT_PROCESS); > >No new entry point, no need to document it.
Big ditto, except obviously both of those need an extra exit code argument. cgf
