*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->IRIX man pages -> Tcl/async (3)              


Tcl_AsyncCreate(3Tcl)					 Tcl_AsyncCreate(3Tcl)

NAME    [Toc]    [Back]

     Tcl_AsyncCreate, Tcl_AsyncMark, Tcl_AsyncInvoke, Tcl_AsyncDelete -	handle
     asynchronous events

SYNOPSIS    [Toc]    [Back]

     #include <tcl.h>

     extern int	tcl_AsyncReady;

     Tcl_AsyncCreate(proc, clientData)


     Tcl_AsyncInvoke(interp, code)


ARGUMENTS    [Toc]    [Back]

     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

     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

     int		code	     (in)      Completion code from command
					       that just completed in interp,
					       or 0 if interp is NULL.

DESCRIPTION    [Toc]    [Back]

     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.

									Page 1

Tcl_AsyncCreate(3Tcl)					 Tcl_AsyncCreate(3Tcl)

     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 completion code returned by that command.  The	command's
     result will be present in interp->result.	When proc returns, whatever it
     leaves in interp->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 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.

     The procedure Tcl_AsyncInvoke is called to	invoke all of the handlers
     that are ready.  The global variable tcl_AsyncReady will be 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 checks
     tcl_AsyncReady after each command is evaluated and	calls Tcl_AsyncInvoke
     if	needed.	 Applications may also call Tcl_AsyncInvoke at interesting
     times for that application.  For example, Tk's event handler checks
     tcl_AsyncReady 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	handler	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 interp->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

									Page 2

Tcl_AsyncCreate(3Tcl)					 Tcl_AsyncCreate(3Tcl)

     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

WARNING    [Toc]    [Back]

     It	is almost always a bad idea for	an asynchronous	event handler to
     modify interp->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	interp->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
     interp->result, errorInfo,	and errorCode, and return the code argument.

KEYWORDS    [Toc]    [Back]

     asynchronous event, handler, signal

									PPPPaaaaggggeeee 3333
[ Back ]
 Similar pages
Name OS Title
st_addr_to_line Tru64 convert an address in an object to a file handle, procedure handle, line number, or symbol handle an...
st_addr_to_file Tru64 convert an address in an object to a file handle, procedure handle, line number, or symbol handle an...
st_addr_to_proc Tru64 convert an address in an object to a file handle, procedure handle, line number, or symbol handle an...
st_addr_to_sym Tru64 convert an address in an object to a file handle, procedure handle, line number, or symbol handle an...
st_data_addr_to_sym Tru64 convert an address in an object to a file handle, procedure handle, line number, or symbol handle an...
st_text_addr_to_sym Tru64 convert an address in an object to a file handle, procedure handle, line number, or symbol handle an...
sleep FreeBSD wait for events
wakeup_one FreeBSD wait for events
evmviewer Tru64 View events
msleep FreeBSD wait for events
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service