Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

how to kill running proc in TCL/tk

1,016 views
Skip to first unread message

Hans

unread,
Jan 31, 2006, 2:39:33 PM1/31/06
to
Hi,
I wrote a TK code, there are some buttons in the panel to invoke some
round check for my network devices, in each check I spawn a telnet to
my device and run command to get response, If no problem found, it will
exit from telnet and sleep for a while , then telnet and check again.
many checks for different device may run at the same time, (that means
many different spawn instances) If no problem, those check will run for
ever.

Now I'm hoping to add a function to stop the running check proc. I hope
I can add a button[stop running] in my panel, if click the button, then
system will kill all running proc, include all telnet session. How can
I do it?

Any response will be very appreciated.

Hans Yin

Hans

unread,
Feb 2, 2006, 3:35:06 AM2/2/06
to
Is there anybody can give me a hand?

thanks in advance.

Victor Wagner

unread,
Feb 2, 2006, 4:41:42 AM2/2/06
to
Hans <han...@gmail.com> wrote:
: Is there anybody can give me a hand?

First, tell us what platform you are running on.

On Unix you have basically two ways of doing so:

1. exec external kill utility, which is guaranteed to exist.
2. Use kill function from Tclx package.

In both cases you need PID of the process. If you've started process
from Tcl using exec with '&' at the end, exec returns you list of PIDs.

If you opened process with open "|program", you can get PID from
tcl filehandle using [pid $filehandle]. But in some cases you don't need
explicitely kill process opened such way. Just closing filehandle is
often enough.

I sometimes write following code:

if {[catch {package require Tclx}]} {
proc kill {signal pid} {
exec kill -$signal $pid
}

}

if I don't need any other functionality from Tclx.
This code does use Tclx if it is avaliable and external kill utility
otherwise.

On Windows things are more complicated. There are several versions of
external kill utilities available - from cygwin, from Resource kit etc.
But they don't exactly work as unix user expect. There is Tclx
extension for Windows, and its kill command is capable of terminating
process (using pid, returned by tcl exec or pid command), but not
sending it arbitrary signal (from the list of those available for
windows).

I would be very grateful myself, if somebody would explain me how to
send Ctrl-Break (aka SIGINT) to windows console process, opened as
bidirectional file (open "|program" r+) from
console Tcl script, which is started from make, without interrupting
script itself and make. Problem is that WinApi allows only to send
CtrlBreak to console (i.e. all aplicatioons which share same console at
once) and this process shares console with tcl script and make, despite
of both input and output being redirected.

--

Uwe Klein

unread,
Feb 2, 2006, 3:56:13 AM2/2/06
to
Hans wrote:
> Is there anybody can give me a hand?
>
> thanks in advance.
>
Hi,

what about:
button .exit -text "Exit" -command exit ; pack .exit

or :
button .exit -text "Exit" -command myexit ; pack .exit

set ::running 1

proc myexit {} {
# don't start any new telnet sessions
set ::running 0
foreach spid $my_spawn_ids {
close $spid ; wait $spid
}
exit
}


uwe

Bryan Oakley

unread,
Feb 2, 2006, 8:39:32 AM2/2/06
to
Hans wrote:
> Is there anybody can give me a hand?
>
> thanks in advance.
>

The answer might be "you can't" if the proc is already running and you
don't want to kill the whole process. That is to say, tcl has no way to
interrupt a running proc or command.

However, you can certainly write procs that are interruptable. If your
proc spends most of its time in a loop, for example, you can check for
the existence of a special variable:

proc foo {} {
while {1} {
<some code>
if {[info exists ::interrupt] && $::interrupt]} break
}
}

If you can better explain what you need we can be more specific. For
example, are you wanting this capabilities for all procs or just your
one proc? If the latter, what is that one proc doing -- is it hung on a
single command (e.g. waiting for input) or is it in a tight loop?

--
Bryan Oakley
http://www.tclscripting.com

Donal K. Fellows

unread,
Feb 2, 2006, 8:45:54 AM2/2/06
to
Bryan Oakley wrote:
> The answer might be "you can't" if the proc is already running and you
> don't want to kill the whole process. That is to say, tcl has no way to
> interrupt a running proc or command.

Not quite true. Tcl 8.5 can interrupt even a running tight loop or
blocking [after], but you need to have set up the time limit before
entering the code to be interrupted. Other forms of interrupt are
possible if you use TclX/Expect's [signal] command, but that's going to
be difficult to make work precisely right.

Donal.

pal...@yahoo.com

unread,
Feb 2, 2006, 8:49:18 AM2/2/06
to

Victor Wagner wrote:
> On Windows things are more complicated. There are several versions of
> external kill utilities available - from cygwin, from Resource kit etc.
> But they don't exactly work as unix user expect. There is Tclx
> extension for Windows, and its kill command is capable of terminating
> process (using pid, returned by tcl exec or pid command), but not
> sending it arbitrary signal (from the list of those available for
> windows).
>

See http://twapi.sf.net/process.html#end_process. This does not send
signals but does it the windows way (graceful WM_EXIT message or a hard
kill if the app does not respond to the message)

> I would be very grateful myself, if somebody would explain me how to
> send Ctrl-Break (aka SIGINT) to windows console process, opened as
> bidirectional file (open "|program" r+) from
> console Tcl script, which is started from make, without interrupting
> script itself and make. Problem is that WinApi allows only to send
> CtrlBreak to console (i.e. all aplicatioons which share same console at
> once) and this process shares console with tcl script and make, despite
> of both input and output being redirected.
>

Unless you specifically want to send signals, just use end_process as
above. If you insist on sending a signal, in the parent process you can
call twapi::set_console_control_handler with a script that ignores
ctrl-c and ctrl-break and then call
twapi::generate_console_control_event to send the ctrl-c.

/Ashok

Victor Wagner

unread,
Feb 2, 2006, 10:03:13 AM2/2/06
to
pal...@yahoo.com wrote:

: > I would be very grateful myself, if somebody would explain me how to


: > send Ctrl-Break (aka SIGINT) to windows console process, opened as
: > bidirectional file (open "|program" r+) from
: > console Tcl script, which is started from make, without interrupting
: > script itself and make. Problem is that WinApi allows only to send
: > CtrlBreak to console (i.e. all aplicatioons which share same console at
: > once) and this process shares console with tcl script and make, despite
: > of both input and output being redirected.
: >
: Unless you specifically want to send signals, just use end_process as
: above. If you insist on sending a signal, in the parent process you can
: call twapi::set_console_control_handler with a script that ignores
: ctrl-c and ctrl-break and then call

It wouldn't help. There is also another process on the same console,
which shouldn't be interrupted too. And there is no good trying to
ignore Ctrl-break in make program, because it is quite useful way to
interrupt make.

And yes, I specifically want to send Ctrl-Break condition to process,
because it handles this condition and outputs some intformation I want
to read and analyze.


I've thought of writing script-wrapper, which would detach from original
console and allocate new one to send control-C too. B


--

MartinLemburg@UGS

unread,
Feb 2, 2006, 10:56:12 AM2/2/06
to
Hello Donal,

I just tried out the "interp limit" command and had problems with it.

The following code I used to try out the "interp limit" command:

% proc limitCB {args} {puts "limitCB [list $args]";}
% puts [interp limit {} time];
% interp limit {} time -command limitCB -seconds 10;

Trying this in the most current tclkitsh85 and tclkit85 (both v8.5a4)
causes the shells to to crash.

The shell printed out the same text to the console, than the wish
showed inside a message box:

| installing limit callback to the limited interpreter

Is this normal? (The message and the crash)

Currently I have no tcl 8.5 installed, perhabs the regular tcl 8.5
behaves different.

Best regards,

Martin Lemburg
UGS - Transforming the Process of Innovation

Donal K. Fellows

unread,
Feb 2, 2006, 11:42:23 AM2/2/06
to
MartinLemburg@UGS wrote:
> The following code I used to try out the "interp limit" command:
>
> % proc limitCB {args} {puts "limitCB [list $args]";}
> % puts [interp limit {} time];
> % interp limit {} time -command limitCB -seconds 10;
>
> Trying this in the most current tclkitsh85 and tclkit85 (both v8.5a4)
> causes the shells to to crash.
>
> The shell printed out the same text to the console, than the wish
> showed inside a message box:
>
> | installing limit callback to the limited interpreter
>
> Is this normal? (The message and the crash)

Time-limited interpreters won't do callbacks into themselves when the
limit is hit (limits work by changing the semantics of quite a few bits
of the language, especially including [catch]). Also, I think the code
is using an absolute deadline and not a relative one (on the grounds
that it means that the value you get back from reading the limit config
is meaningful...)

BTW, when you say "crash" what exactly do you mean? Do you mean "dump
core" or do you mean "exit unexpectedly in an uncontrolled way"? :-)

Donal.

MartinLemburg@UGS

unread,
Feb 2, 2006, 11:53:31 AM2/2/06
to
Hi Donal,

with crash I mean "dump core".

XP asks me if I want to debug or to close the tclkit85 session, after
clicking on the button of the messagebox.

But ... I'm not sure, if I understand your explaination about the
limits callback.
And ... I didn't understand the man page too - so far as it seems to.

Donal K. Fellows

unread,
Feb 3, 2006, 4:16:00 AM2/3/06
to
MartinLemburg@UGS wrote:
> with crash I mean "dump core".

OK, that's what is not supposed to happen. :-(

> But ... I'm not sure, if I understand your explaination about the
> limits callback.
> And ... I didn't understand the man page too - so far as it seems to.

It does seem that some improvement is needed there. :-/ Yet another
thing to do when I have time.

Donal.

0 new messages