Planet
navi homePPSaboutscreenshotsdownloaddevelopmentforum

source: downloads/tcl8.5.2/doc/Limit.3 @ 35

Last change on this file since 35 was 25, checked in by landauf, 18 years ago

added tcl to libs

File size: 7.7 KB
Line 
1'\"
2'\" Copyright (c) 2004 Donal K. Fellows
3'\"
4'\" See the file "license.terms" for information on usage and redistribution
5'\" of this file, and for a DISCLAIMER OF ALL WARRANTIES.
6'\"
7'\" RCS: @(#) $Id: Limit.3,v 1.7 2004/11/12 09:01:25 das Exp $
8'\"
9.so man.macros
10.TH Tcl_LimitCheck 3 8.5 Tcl "Tcl Library Procedures"
11.BS
12.SH NAME
13Tcl_LimitAddHandler, Tcl_LimitCheck, Tcl_LimitExceeded, Tcl_LimitGetCommands, Tcl_LimitGetGranularity, Tcl_LimitGetTime, Tcl_LimitReady, Tcl_LimitRemoveHandler, Tcl_LimitSetCommands, Tcl_LimitSetGranularity, Tcl_LimitSetTime, Tcl_LimitTypeEnabled, Tcl_LimitTypeExceeded, Tcl_LimitTypeReset, Tcl_LimitTypeSet \- manage and check resource limits on interpreters
14.SH SYNOPSIS
15.nf
16\fB#include <tcl.h>\fR
17.sp
18int
19\fBTcl_LimitCheck\fR(\fIinterp\fR)
20.sp
21int
22\fBTcl_LimitReady\fR(\fIinterp\fR)
23.sp
24int
25\fBTcl_LimitExceeded\fR(\fIinterp\fR)
26.sp
27int
28\fBTcl_LimitTypeExceeded\fR(\fIinterp, type\fR)
29.sp
30int
31\fBTcl_LimitTypeEnabled\fR(\fIinterp, type\fR)
32.sp
33void
34\fBTcl_LimitTypeSet\fR(\fIinterp, type\fR)
35.sp
36void
37\fBTcl_LimitTypeReset\fR(\fIinterp, type\fR)
38.sp
39int
40\fBTcl_LimitGetCommands\fR(\fIinterp\fR)
41.sp
42void
43\fBTcl_LimitSetCommands\fR(\fIinterp, commandLimit\fR)
44.sp
45void
46\fBTcl_LimitGetTime\fR(\fIinterp, timeLimitPtr\fR)
47.sp
48void
49\fBTcl_LimitSetTime\fR(\fIinterp, timeLimitPtr\fR)
50.sp
51int
52\fBTcl_LimitGetGranularity\fR(\fIinterp, type\fR)
53.sp
54void
55\fBTcl_LimitSetGranularity\fR(\fIinterp, type, granularity\fR)
56.sp
57void
58\fBTcl_LimitAddHandler\fR(\fIinterp, type, handlerProc, clientData, deleteProc\fR)
59.sp
60void
61\fBTcl_LimitRemoveHandler\fR(\fIinterp, type, handlerProc, clientData\fR)
62.SH ARGUMENTS
63.AS Tcl_LimitHandlerDeleteProc commandLimit in/out
64.AP Tcl_Interp *interp in
65Interpreter that the limit being managed applies to or that will have
66its limits checked.
67.AP int type in
68The type of limit that the operation refers to.  This must be either
69\fBTCL_LIMIT_COMMANDS\fR or \fBTCL_LIMIT_TIME\fR.
70.AP int commandLimit in
71The maximum number of commands (as reported by \fBinfo cmdcount\fR)
72that may be executed in the interpreter.
73.AP Tcl_Time *timeLimitPtr in/out
74A pointer to a structure that will either have the new time limit read
75from (\fBTcl_LimitSetTime\fR) or the current time limit written to
76(\fBTcl_LimitGetTime\fR).
77.AP int granularity in
78Divisor that indicates how often a particular limit should really be
79checked.  Must be at least 1.
80.AP Tcl_LimitHandlerProc *handlerProc in
81Function to call when a particular limit is exceeded.  If the
82\fIhandlerProc\fR removes or raises the limit during its processing,
83the limited interpreter will be permitted to continue to process after
84the handler returns.  Many handlers may be attached to the same
85interpreter limit; their order of execution is not defined, and they
86must be identified by \fIhandlerProc\fR and \fIclientData\fR when they
87are deleted.
88.AP ClientData clientData in
89Arbitrary pointer-sized word used to pass some context to the
90\fIhandlerProc\fR function.
91.AP Tcl_LimitHandlerDeleteProc *deleteProc in
92Function to call whenever a handler is deleted.  May be NULL if the
93\fIclientData\fR requires no deletion.
94.BE
95
96.SH DESCRIPTION
97.PP
98Tcl's interpreter resource limit subsystem allows for close control
99over how much computation time a script may use, and is useful for
100cases where a program is divided into multiple pieces where some parts
101are more trusted than others (e.g. web application servers).
102.PP
103Every interpreter may have a limit on the wall-time for execution, and
104a limit on the number of commands that the interpreter may execute.
105Since checking of these limits is potentially expensive (especially
106the time limit), each limit also has a checking granularity, which is
107a divisor for an internal count of the number of points in the core
108where a check may be performed (which is immediately before executing
109a command and at an unspecified frequency between running commands,
110which can happen in empty-bodied \fBwhile\fR loops).
111.PP
112The final component of the limit engine is a callback scheme which
113allows for notifications of when a limit has been exceeded.  These
114callbacks can just provide logging, or may allocate more resources to
115the interpreter to permit it to continue processing longer.
116.PP
117When a limit is exceeded (and the callbacks have run; the order of
118execution of the callbacks is unspecified) execution in the limited
119interpreter is stopped by raising an error and setting a flag that
120prevents the \fBcatch\fR command in that interpreter from trapping
121that error.  It is up to the context that started execution in that
122interpreter (typically a master interpreter) to handle the error.
123.SH "LIMIT CHECKING API"
124.PP
125To check the resource limits for an interpreter, call
126\fBTcl_LimitCheck\fR, which returns \fBTCL_OK\fR if the limit was not
127exceeded (after processing callbacks) and \fBTCL_ERROR\fR if the limit was
128exceeded (in which case an error message is also placed in the
129interpreter result).  That function should only be called when
130\fBTcl_LimitReady\fR returns non-zero so that granularity policy is
131enforced.  This API is designed to be similar in usage to
132\fBTcl_AsyncReady\fR and \fBTcl_AsyncInvoke\fR.
133.PP
134When writing code that may behave like \fBcatch\fR in respect of
135errors, you should only trap an error if \fBTcl_LimitExceeded\fR
136returns zero.  If it returns non-zero, the interpreter is in a
137limit-exceeded state and errors should be allowed to propagate to the
138calling context.  You can also check whether a particular type of
139limit has been exceeded using \fBTcl_LimitTypeExceeded\fR.
140.SH "LIMIT CONFIGURATION"
141.PP
142To check whether a limit has been set (but not whether it has actually
143been exceeded) on an interpreter, call \fBTcl_LimitTypeEnabled\fR with
144the type of limit you want to check.  To enable a particular limit
145call \fBTcl_LimitTypeSet\fR, and to disable a limit call
146\fBTcl_LimitTypeReset\fR.
147.PP
148The level of a command limit may be set using
149\fBTcl_LimitSetCommands\fR, and retrieved using
150\fBTcl_LimitGetCommands\fR.  Similarly for a time limit with
151\fBTcl_LimitSetTime\fR and \fBTcl_LimitGetTime\fR respectively, but
152with that API the time limit is copied from and to the Tcl_Time
153structure that the \fItimeLimitPtr\fR argument points to.
154.PP
155The checking granularity for a particular limit may be set using
156\fBTcl_LimitSetGranularity\fR and retrieved using
157\fBTcl_LimitGetGranularity\fR.  Note that granularities must always be
158positive.
159.SS "LIMIT CALLBACKS"
160.PP
161To add a handler callback to be invoked when a limit is exceeded, call
162\fBTcl_LimitAddHandler\fR.  The \fIhandlerProc\fR argument describes
163the function that will actually be called; it should have the
164following prototype:
165.PP
166.CS
167typedef void Tcl_LimitHandlerProc(
168        ClientData \fIclientData\fR,
169        Tcl_Interp *\fIinterp\fR);
170.CE
171.PP
172The \fIclientData\fR argument to the handler will be whatever is
173passed to the \fIclientData\fR argment to \fBTcl_LimitAddHandler\fR,
174and the \fIinterp\fR is the interpreter that had its limit exceeded.
175.PP
176The \fIdeleteProc\fR argument to \fBTcl_LimitAddHandler\fR is a
177function to call to delete the \fIclientData\fR value.  It may be
178\fBTCL_STATIC\fR or NULL if no deletion action is necessary, or
179\fBTCL_DYNAMIC\fR if all that is necessary is to free the structure with
180\fBTcl_Free\fR.  Otherwise, it should refer to a function with the
181following prototype:
182.PP
183.CS
184typedef void Tcl_LimitHandlerDeleteProc(
185        ClientData \fIclientData\fR);
186.CE
187.PP
188A limit handler may be deleted using \fBTcl_LimitRemoveHandler\fR; the
189handler removed will be the first one found (out of the handlers added
190with \fBTcl_LimitAddHandler\fR) with exactly matching \fItype\fR,
191\fIhandlerProc\fR and \fIclientData\fR arguments.  This function
192always invokes the \fIdeleteProc\fR on the \fIclientData\fR (unless
193the \fIdeleteProc\fR was NULL or \fBTCL_STATIC\fR).
194
195.SH KEYWORDS
196interpreter, resource, limit, commands, time, callback
Note: See TracBrowser for help on using the repository browser.