diff options
Diffstat (limited to 'doc/Async.3')
| -rw-r--r-- | doc/Async.3 | 45 |
1 files changed, 25 insertions, 20 deletions
diff --git a/doc/Async.3 b/doc/Async.3 index 5086557..558b511 100644 --- a/doc/Async.3 +++ b/doc/Async.3 @@ -5,10 +5,8 @@ '\" See the file "license.terms" for information on usage and redistribution '\" of this file, and for a DISCLAIMER OF ALL WARRANTIES. '\" -'\" RCS: @(#) $Id: Async.3,v 1.3 1999/04/16 00:46:30 stanton Exp $ -'\" -.so man.macros .TH Tcl_AsyncCreate 3 7.0 Tcl "Tcl Library Procedures" +.so man.macros .BS .SH NAME Tcl_AsyncCreate, Tcl_AsyncMark, Tcl_AsyncInvoke, Tcl_AsyncDelete, Tcl_AsyncReady \- handle asynchronous events @@ -50,9 +48,9 @@ or 0 if \fIinterp\fR 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 +evaluated then it is not safe to take any substantive action to process the event. -For example, it isn't safe to evaluate a Tcl script since the +For example, it is not 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. @@ -60,6 +58,13 @@ 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. .PP +\fBTcl_AsyncCreate\fR, \fBTcl_AsyncDelete\fR, and \fBTcl_AsyncReady\fR +are thread sensitive. They access and/or set a thread-specific data +structure in the event of a core built with \fI\-\-enable\-threads\fR. The token +created by \fBTcl_AsyncCreate\fR contains the needed thread information it +was called from so that calling \fBTcl_AsyncMark\fR(\fItoken\fR) will only yield +the origin thread into the asynchronous handler. +.PP \fBTcl_AsyncCreate\fR creates an asynchronous handler and returns a token for it. The asynchronous handler must be created before @@ -76,12 +81,14 @@ the world is in a safe state, and \fIproc\fR can then carry out the actions associated with the asynchronous event. \fIProc\fR should have arguments and result that match the type \fBTcl_AsyncProc\fR: +.PP .CS -typedef int Tcl_AsyncProc( - ClientData \fIclientData\fR, - Tcl_Interp *\fIinterp\fR, - int \fIcode\fR); +typedef int \fBTcl_AsyncProc\fR( + ClientData \fIclientData\fR, + Tcl_Interp *\fIinterp\fR, + int \fIcode\fR); .CE +.PP The \fIclientData\fR will be the same as the \fIclientData\fR argument passed to \fBTcl_AsyncCreate\fR when the handler was created. @@ -90,8 +97,8 @@ execution in an interpreter, then \fIinterp\fR will identify the interpreter in which the command was evaluated and \fIcode\fR will be the completion code returned by that command. -The command's result will be present in \fIinterp->result\fR. -When \fIproc\fR returns, whatever it leaves in \fIinterp->result\fR +The command's result will be present in the interpreter's result. +When \fIproc\fR returns, whatever it leaves in the interpreter's result will be returned as the result of the command and the integer value returned by \fIproc\fR will be used as the new completion code for the command. @@ -127,7 +134,7 @@ not be invoked. If multiple handlers become active at the same time, the handlers are invoked in the order they were created (oldest handler first). -The \fIcode\fR and \fIinterp->result\fR for later handlers +The \fIcode\fR 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. @@ -135,22 +142,20 @@ If new handlers become ready while handlers are executing, \fBTcl_AsyncInvoke\fR will invoke them all; at each point it invokes the highest-priority (oldest) ready handler, repeating this over and over until there are no longer any ready handlers. - .SH WARNING .PP It is almost always a bad idea for an asynchronous event -handler to modify \fIinterp->result\fR or return a code different +handler to modify the interpreter's result or return a code different from its \fIcode\fR 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 \fIinterp->result\fR plus the values -of the variables \fBerrorInfo\fR and \fBerrorCode\fR (this can -be done, for example, by storing them in dynamic strings). +then it should first save the interpreter's state by calling +\fBTcl_SaveInterpState\fR, passing in the \fIcode\fR argument. When the asynchronous handler is finished it should restore -\fIinterp->result\fR, \fBerrorInfo\fR, and \fBerrorCode\fR, -and return the \fIcode\fR argument. +the interpreter's state by calling \fBTcl_RestoreInterpState\fR, +and then returning the \fIcode\fR argument. .SH KEYWORDS -asynchronous event, handler, signal +asynchronous event, handler, signal, Tcl_SaveInterpState, thread |