{"thread":{"id":"43524","subject":"Easy shell question: how to make a script killing all his childs when killed?","startedAt":"2006-12-09T15:16:32Z","lastAt":"2006-12-10T14:25:58Z","messageCount":6,"participants":["Marco Costalba","Alex Riesen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"295272","messageId":"e5bfff550612090716p215167b9r2277b09c09b18894@mail.gmail.com","threadId":"43524","inReplyTo":null,"subject":"Easy shell question: how to make a script killing all his childs when killed?","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-12-09T15:16:32Z","receivedAt":"2006-12-09T15:16:32Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"Ok. I am really bad at scripting, so perhaps my question is very silly, but...\n\nI create and run a script with the content:\n\ngit rev-list --header --boundary --parents --topo-order 2229ff5c7c  >\n/tmp/qgit_135902672.txt\n\nThen I kill the script while it's running, but his child\n(git-rev-list) continues to run in background and I would like to stop\nit either.\n\nSo how can I write the script to be sure that when stopped, it will\nkill all his childern?\n\nThanks\nMarco\n\nP.S: I have no way to exec the script in fancy ways, I can just start\n"},{"id":"298335","messageId":"20061209173703.GA12373@steel.home","threadId":"43524","inReplyTo":"e5bfff550612090716p215167b9r2277b09c09b18894@mail.gmail.com","subject":"Re: Easy shell question: how to make a script killing all his childs when killed?","fromName":"Alex Riesen","fromEmail":"fork0@t-online.de","sentAt":"2006-12-09T17:37:03Z","receivedAt":"2006-12-09T17:37:03Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Marco Costalba, Sat, Dec 09, 2006 16:16:32 +0100:\n> So how can I write the script to be sure that when stopped, it will\n> kill all his childern?\n\nStrictly speaking: you can't. Anything you'd try will either be not\nportable or involve quiet complex dependencies (like perl).\nAre you sure you can't control each process independently?\n\nSpeaking not so strictly, you can use a script engine which supports\neither signal handling or exit notification (i.e. sh has traps and\nperl has %SIG and END{}). It's unsafe, ugly and not quiet portable to\nthat other operating system, but it often works and is (ab)used.\n\n> P.S: I have no way to exec the script in fancy ways, I can just start\n> it and get is PID.\n\nWhich is \"fancy\" enough. What do you mean \"start\"? Starting a new\nprocess usually and notably involves forking and execing (even if the\nfirst thing to exec will be your shell).\n"},{"id":"297819","messageId":"e5bfff550612090951l43a83a00o7ea2e244ca562c77@mail.gmail.com","threadId":"43524","inReplyTo":"20061209173703.GA12373@steel.home","subject":"Re: Easy shell question: how to make a script killing all his childs when killed?","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-12-09T17:51:57Z","receivedAt":"2006-12-09T17:51:57Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 12/9/06, Alex Riesen <fork0@t-online.de> wrote:\n> Marco Costalba, Sat, Dec 09, 2006 16:16:32 +0100:\n>\n> > P.S: I have no way to exec the script in fancy ways, I can just start\n> > it and get is PID.\n>\n> Which is \"fancy\" enough. What do you mean \"start\"? Starting a new\n> process usually and notably involves forking and execing (even if the\n> first thing to exec will be your shell).\n>\n>\n\nBy 'start' I mean it is done inside Qt QProcess class back box ;-)\n\nAnyway I have written an homegrown 'wanna be hacker' launching script:\n\ngit rev-list --header --boundary --parents --topo-order HEAD >\n/tmp/qgit_136224752.txt &\necho $!\nwait\n\n\nWith this I can get the pid of git-rev-list from my QProcess interface\nso to be able to kill it when needed with another command ('kill'\nBTW).\n\nI have googled around and it seems that 'echo $!' and 'wait' _should_\nbe portable among many shell, please correct me if'm wrong or if the\napproach is failing (I already know it's ugly ;-)  )\n\n"},{"id":"298641","messageId":"20061209213937.GB12373@steel.home","threadId":"43524","inReplyTo":"e5bfff550612090951l43a83a00o7ea2e244ca562c77@mail.gmail.com","subject":"Re: Easy shell question: how to make a script killing all his childs when killed?","fromName":"Alex Riesen","fromEmail":"fork0@t-online.de","sentAt":"2006-12-09T21:39:37Z","receivedAt":"2006-12-09T21:39:37Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Marco Costalba, Sat, Dec 09, 2006 18:51:57 +0100:\n> >> P.S: I have no way to exec the script in fancy ways, I can just start\n> >> it and get is PID.\n> >\n> >Which is \"fancy\" enough. What do you mean \"start\"? Starting a new\n> >process usually and notably involves forking and execing (even if the\n> >first thing to exec will be your shell).\n> \n> By 'start' I mean it is done inside Qt QProcess class back box ;-)\n> \n> Anyway I have written an homegrown 'wanna be hacker' launching script:\n> \n> git rev-list --header --boundary --parents --topo-order HEAD >\n> /tmp/qgit_136224752.txt &\n> echo $!\n> wait\n> \n> With this I can get the pid of git-rev-list from my QProcess interface\n> so to be able to kill it when needed with another command ('kill'\n> BTW).\n\nWhy do you need to save it in temporary file at all? Why don't you\nread the output like gitk does?  You can take a look at popen(3). It's\nknown to be portable among operating systems and libc's.  Or, BTW, why\ndon't you just read qprocess.h, use processIdentifier()/pid(),\nread*()-methods and the like?  (though, looking at the QProcess in\n"},{"id":"296880","messageId":"e5bfff550612091506g41e40e87n6356b8ddd5e16a5d@mail.gmail.com","threadId":"43524","inReplyTo":"20061209213937.GB12373@steel.home","subject":"Re: Easy shell question: how to make a script killing all his childs when killed?","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-12-09T23:06:34Z","receivedAt":"2006-12-09T23:06:34Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 12/9/06, Alex Riesen <fork0@t-online.de> wrote:\n>\n> Why do you need to save it in temporary file at all? Why don't you\n> read the output like gitk does?  You can take a look at popen(3). It's\n> known to be portable among operating systems and libc's.  Or, BTW, why\n> don't you just read qprocess.h, use processIdentifier()/pid(),\n> read*()-methods and the like?  (though, looking at the QProcess in\n> qt3, I wouldn't really blame you)\n>\n\nWell, I _used_ QProcess interface until last week. It's socket based\nand it's quite fast (much more then gitk BTW), but due to some\ninternal buffering not so fast as reading from a file (in my last post\nregarding git-rev-list access there are some performance numbers to\ndocument this). It seems that socket/pipe based IPC is not as fast as\nfile write/read. Of course we are talking of OS cached files, no disk\naccess must be involved to keep the speed.\n\nProbably someone more versed in IPC and OS internals could comment on\nthis, I just base my arguments on experimental testing of various IPC\nsystems without going deep in the reasons why the number are like\nthis, also because I don't have the necessary knowledge.\n\nBut the fact is that with temporary (in memory) data exchange file the\nload time has been reduced by 40% against socket based QProcess\ninterface.\n\nRegarding gitk we are at least one order of magnitude faster both with\nQProcess and, more, with temporary files, so it's not a useful\nreference in this case.\n\n  Marco\n\nP.S: I didn't experiment with popen(). Thanks for the hint, I will\n"},{"id":"296955","messageId":"20061210142558.GA4836@steel.home","threadId":"43524","inReplyTo":"e5bfff550612091506g41e40e87n6356b8ddd5e16a5d@mail.gmail.com","subject":"Re: Easy shell question: how to make a script killing all his childs when killed?","fromName":"Alex Riesen","fromEmail":"fork0@t-online.de","sentAt":"2006-12-10T14:25:58Z","receivedAt":"2006-12-10T14:25:58Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Marco Costalba, Sun, Dec 10, 2006 00:06:34 +0100:\n> On 12/9/06, Alex Riesen <fork0@t-online.de> wrote:\n> >\n> >Why do you need to save it in temporary file at all? Why don't you\n> >read the output like gitk does?  You can take a look at popen(3). It's\n> >known to be portable among operating systems and libc's.  Or, BTW, why\n> >don't you just read qprocess.h, use processIdentifier()/pid(),\n> >read*()-methods and the like?  (though, looking at the QProcess in\n> >qt3, I wouldn't really blame you)\n> >\n> \n> Well, I _used_ QProcess interface until last week. It's socket based\n> and it's quite fast (much more then gitk BTW), but due to some\n> internal buffering not so fast as reading from a file (in my last post\n> regarding git-rev-list access there are some performance numbers to\n> document this). It seems that socket/pipe based IPC is not as fast as\n> file write/read. Of course we are talking of OS cached files, no disk\n> access must be involved to keep the speed.\n\nOh, I see now (\"Fast access git-rev-list output...\").\n\nBTW, I just cannot reproduce that at all (on Linux):\n\n    time { git rev-list --all > /tmp/ggg; cat /tmp/ggg >/dev/null; }\n\ntends to be somewhat slower than\n\n    time git rev-list --all | cat >/dev/null\n\nQProcess must be doing something stupid.\n\n> Regarding gitk we are at least one order of magnitude faster both with\n> QProcess and, more, with temporary files, so it's not a useful\n> reference in this case.\n\nDunno. It's hard to assess on \"small\" repos, like kernel. They feel\nalmost equally fast (maybe because qgit checks working directory too).\nHaven't tried QGit on Windows yet (does it work there?).\n\n> P.S: I didn't experiment with popen(). Thanks for the hint, I will\n> give it a try ;-)\n\npopen(3) usually uses pipe(2). It's also awkward with regard to\nshell metacharacters and signals (as system(3) is). You can use your'\nown buffers (setvbuf) so that could be a win against QProcess.\n"}]}