Tcl_AsyncHandler Tcl_AsyncCreate(proc, clientData)
int Tcl_AsyncInvoke(interp, code)
- Tcl_AsyncProc *proc (in)
Procedure to invoke to handle an asynchronous event.
- ClientData clientData (in)
One-word value to pass to proc.
- Tcl_AsyncHandler async (in)
Token for asynchronous event handler.
- Tcl_Interp *interp (in)
Tcl interpreter in which command was being evaluated when handler was invoked, or NULL if handler was invoked when there was no interpreter active.
- int code (in)
Completion code from command that just completed in interp, or 0 if interp is NULL.
These procedures provide a safe mechanism for dealing with asynchronous events such as signals. If an event such as a signal occurs while a Tcl script is being evaluated then it isn't safe to take any substantive action to process the event. For example, it isn't safe to evaluate a Tcl script since the interpreter may already be in the middle of evaluating a script; it may not even be safe to allocate memory, since a memory allocation could have been in progress when the event occurred. The only safe approach is to set a flag indicating that the event occurred, then handle the event later when the world has returned to a clean state, such as after the current Tcl command completes.
typedef int Tcl_AsyncProc( ClientData clientData, Tcl_Interp *interp, int code);
The clientData will be the same as the
argument passed to
It is also possible for proc to be invoked when no interpreter is active. This can happen, for example, if an asynchronous event occurs while the application is waiting for interactive input or an X event. In this case interp will be NULL and code will be 0, and the return value from proc will be ignored.
If multiple handlers become active at the same time, the
handlers are invoked in the order they were created (oldest
The code and the interpreter's result for later handlers
reflect the values returned by earlier handlers, so that
the most recently created handler has last say about
the interpreter's result and completion code.
If new handlers become ready while handlers are executing,
It is almost always a bad idea for an asynchronous event handler to modify the interpreter's result or return a code different from its code argument. This sort of behavior can disrupt the execution of scripts in subtle ways and result in bugs that are extremely difficult to track down. If an asynchronous event handler needs to evaluate Tcl scripts then it should first save the interpreter's result plus the values of the variables errorInfo and errorCode (this can be done, for example, by storing them in dynamic strings). When the asynchronous handler is finished it should restore the interpreter's result, errorInfo, and errorCode, and return the code argument.
Windows Server 2012. Windows 8.1. Windows Server 2012 R2. Windows 10. Windows Server 2016. Windows Server 2019.
PTC MKS Toolkit for Professional Developers
PTC MKS Toolkit for Enterprise Developers
PTC MKS Toolkit for Enterprise Developers 64-Bit Edition
PTC MKS Toolkit 10.3 Documentation Build 39.