Hi,
I have a third idea to suggest: what if we just added an exit or
die or whatever command to automate? Then one could conveniently,
deterministically, and portably kill off an automate stdio process,
without all this mess with signals. Just issue the command, then wait
for the pipe to be
Hallo,
On 5/22/06, Thomas Keller [EMAIL PROTECTED] wrote:
int count = 0
while (still_running() ++count 10) {
send_sigterm();
sleep(1);
}
while (still_running()) send_sigkill();
Hum... I just close the input and output pipes and then wait()
for the process to die.
--
-alex
Nathaniel Smith wrote:
int count = 0
while (still_running() ++count 10) {
send_sigterm();
sleep(1);
}
while (still_running()) send_sigkill();
Ew, indeed, that's no fun (and not very portable, either).
Hrm... maybe we've misunderstood each other. Qt comes with generalized
terminate()
Thomas,
Thomas Keller wrote:
Again, if WM_CLOSE is correctly interpreted on Windows mtn builds as
equivalent to SIGTERM, Qt should do the trick and there wouldn't be
any need for such a function. But thanks!
It was my impression that WM_CLOSE is a message which can only be sent
to a window
Markus Meyer wrote:
Thomas,
Thomas Keller wrote:
Again, if WM_CLOSE is correctly interpreted on Windows mtn builds as
equivalent to SIGTERM, Qt should do the trick and there wouldn't be
any need for such a function. But thanks!
It was my impression that WM_CLOSE is a message which can only be
On Tuesday 23 May 2006 14:40, rghetta wrote:
AFAIK, you can intercept a WM_CLOSE in a console app by adding a CTRL-C
handler (via SetConsoleCtrlHandler).
A 'close' command for the 'automate stdio' interface would imho be *much*
cleaner and more portable.
BTW, how do I distinguish between
On Mon, May 22, 2006 at 11:53:43PM +0200, Thomas Keller wrote:
During my work for guitone I noticed that I eventually need to kill and
restart the mtn automate stdio process, because when I change the
workspace to some other directory, the working directory of the created
and running process
