On 2012-08-07 08:26:46 -0700, Jonathan Nieder wrote: > Vincent Lefevre wrote: > > On 2012-08-02 11:03:11 -0700, Jonathan Nieder wrote: > > >> How about this patch (which at least gets rid of a mysterious code > >> artifact)? > > > > This is worse: Ctrl-G in emacs kills emacs! > > Weird. Why does system(3) claim it sets SIGINT to SIG_IGN, then?
Well, this is from POSIX: http://pubs.opengroup.org/onlinepubs/9699919799/functions/system.html It is said: The system() function shall behave as if a child process were created using fork(), and the child process invoked the sh utility using execl() as follows: execl(<shell path>, "sh", "-c", command, (char *)0); where <shell path> is an unspecified pathname for the sh utility. It is unspecified whether the handlers registered with pthread_atfork() are called as part of the creation of the child process. The system() function shall ignore the SIGINT and SIGQUIT signals, and shall block the SIGCHLD signal, while waiting for the command to terminate. If this might cause the application to miss a signal that would have killed it, then the application should examine the return value from system() and take whatever action is appropriate to the application if the command terminated due to receipt of a signal. The rationale makes it clear about which process(es) shall ignore these signals: Ignoring SIGINT and SIGQUIT in the parent process prevents coordination problems (two processes reading from the same terminal, for example) when the executed command ignores or catches one of the signals. and from the example implementation, one can see that the previous actions are restored in the child, just before executing /bin/sh. This contradicts the glibc manual, which doesn't claim to do anything concerning signals in the system() implementation (and in some other discussion, it was said that glibc does only what is written): -- Function: int system (const char *COMMAND) This function executes COMMAND as a shell command. In the GNU C library, it always uses the default shell `sh' to run the command. In particular, it searches the directories in `PATH' to find programs to execute. The return value is `-1' if it wasn't possible to create the shell process, and otherwise is the status of the shell process. *Note Process Completion::, for details on how this status code can be interpreted. If the COMMAND argument is a null pointer, a return value of zero indicates that no command processor is available. This function is a cancellation point in multi-threaded programs. This is a problem if the thread allocates some resources (like memory, file descriptors, semaphores or whatever) at the time `system' is called. If the thread gets canceled these resources stay allocated until the program ends. To avoid this calls to `system' should be protected using cancellation handlers. The `system' function is declared in the header file `stdlib.h'. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
