Malcom.Bright@jet.uk said:
Malcom> I am having a problem getting scotty scripts that
Malcom> terminate with a code error to die. An error message
Malcom> is printed and then the task hangs. Is this a known
Malcom> problem? Is there a fix or a known work around.
This it is not really a problem but a feature. Scotty is completely
event driven, much the same as Tk. The basic event loop is very
simple:
static void
EventLoop(interp)
Tcl_Interp *interp;
{
while (Tk_DoOneEvent(0)) {
/* empty loop body */
}
}
This loop stops if Tk_DoOneEvent() returns 0. This happens if there
are no more timer events registered in the event loop and there are no
file descriptors left to listen to. A scotty script therefore exits if
all file event handlers (this includes all SNMP sessions) are closed
and if there are no timer events left.
All Tcl code is evaluated in Tk_DoOneEvent(). If the evaluation stops
due to an error, Tk_DoOneEvent() will try to call the tkerror Tcl proc.
It is defined in /usr/local/lib/scotty/init.tcl:
proc tkerror {msg} {
global errorInfo
puts stderr $errorInfo
}
You can redefine this default error handler to do whatever you like,
e.g. exiting your script after printing the error message.
Malcom> My code has 1 timer (after) that has just triggered
Malcom> and several snmp sessions - none are async.
The SNMP interface does not distinguish between synchronous and
asynchronous sessions. Hence, the file descriptor in you example is
used for receiving asynchronous SNMP requests, even if you don't
invoke asynchonous SNMP operations.
Juergen