ADC Home > Reference Library > Reference > Mac OS X > Mac OS X Man Pages

 

This document is a Mac OS X manual page. Manual pages are a command-line technology for providing documentation. You can view these manual pages locally using the man(1) command. These manual pages come from many different sources, and thus, have a variety of writing styles.

This manual page is associated with the Mac OS X developer tools. The software or headers described may not be present on your Mac OS X installation until you install the developer tools package. This package is available on your Mac OS X installation DVD, and the latest versions can be downloaded from developer.apple.com.

For more information about the manual page format, see the manual page for manpages(5).



Tcl_AsyncCreate(3)                         Tcl Library Procedures                         Tcl_AsyncCreate(3)



____________________________________________________________________________________________________________

NAME
       Tcl_AsyncCreate,  Tcl_AsyncMark,  Tcl_AsyncInvoke, Tcl_AsyncDelete, Tcl_AsyncReady - handle asynchro-nous asynchronous
       nous events

SYNOPSIS
       #include <tcl.h>

       Tcl_AsyncHandler
       Tcl_AsyncCreate(proc, clientData)

       Tcl_AsyncMark(async)

       int
       Tcl_AsyncInvoke(interp, code)

       Tcl_AsyncDelete(async)

       int
       Tcl_AsyncReady()

ARGUMENTS
       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.
____________________________________________________________________________________________________________


DESCRIPTION
       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 allo-cate allocate
       cate 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.

       Tcl_AsyncCreate,  Tcl_AsyncDelete, and Tcl_AsyncReady are thread sensitive.  They access and/or set a
       thread-specific data structure in the event of an --enable-thread built core.  The token  created  by
       Tcl_AsyncCreate  contains the needed thread information it was called from so that calling Tcl_Async-Mark(token) Tcl_AsyncMark(token)
       Mark(token) will only yield the origin thread into the AsyncProc.

       Tcl_AsyncCreate creates an asynchronous handler and returns a token for it.  The asynchronous handler
       must be created before any occurrences of the asynchronous event that it is intended to handle (it is
       not safe to create a handler at the time of an event).  When an asynchronous event  occurs  the  code
       that  detects  the  event (such as a signal handler) should call Tcl_AsyncMark with the token for the
       handler.  Tcl_AsyncMark will mark the handler as ready to execute, but it will not invoke the handler
       immediately.   Tcl  will call the proc associated with the handler later, when the world is in a safe
       state, and proc can then carry out the actions associated with the asynchronous event.   Proc  should
       have arguments and result that match the type Tcl_AsyncProc:
              typedef int Tcl_AsyncProc(
                ClientData clientData,
                Tcl_Interp *interp,
                int code);
       The clientData will be the same as the clientData argument passed to Tcl_AsyncCreate when the handler
       was created.  If proc is invoked just after a command has completed execution in an interpreter, then
       interp  will identify the interpreter in which the command was evaluated and code will be the comple-tion completion
       tion code returned by that command.  The command's  result  will  be  present  in  the  interpreter's
       result.   When  proc  returns, whatever it leaves in the interpreter's result will be returned as the
       result of the command and the integer value returned by proc will be used as the new completion  code
       for the command.

       It is also possible for proc to be invoked when no interpreter is active.  This can happen, for exam-ple, example,
       ple, 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.

       The procedure Tcl_AsyncInvoke is called to invoke all of the handlers that are ready.  The  procedure
       Tcl_AsyncReady  will return non-zero whenever any asynchronous handlers are ready;  it can be checked
       to avoid calls to Tcl_AsyncInvoke when there are no ready handlers.  Tcl calls  Tcl_AsyncReady  after
       each command is evaluated and calls Tcl_AsyncInvoke if needed.  Applications may also call Tcl_Async-Invoke Tcl_AsyncInvoke
       Invoke at interesting times for that application.  For example, Tcl's event handler  calls  Tcl_Asyn-cReady Tcl_AsyncReady
       cReady  after  each  event  and  calls  Tcl_AsyncInvoke  if needed.  The interp and code arguments to
       Tcl_AsyncInvoke have the same meaning as for proc:  they identify the active interpreter, if any, and
       the completion code from the command that just completed.

       Tcl_AsyncDelete removes an asynchronous handler so that its proc will never be invoked again.  A han-dler handler
       dler can be deleted even when ready, and it will still 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 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,
       Tcl_AsyncInvoke 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.


WARNING
       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 asyn-chronous asynchronous
       chronous 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.


KEYWORDS
       asynchronous event, handler, signal



Tcl                                                  7.0                                  Tcl_AsyncCreate(3)

Did this document help you?
Yes: Tell us what works for you.
It’s good, but: Report typos, inaccuracies, and so forth.
It wasn’t helpful: Tell us what would have helped.