bionic (3) ns_proxy.3aolserver.gz
NAME
ns_proxy - Proxy-process Tcl interface
SYNOPSIS
ns_proxy active pool
ns_proxy cleanup
ns_proxy config pool ?-opt val -opt val ...
ns_proxy eval handle script ?timeout?
ns_proxy get pool ?-handle n -timeout ms?
ns_proxy ping handle
ns_proxy release handle
ns_proxy recv handle
ns_proxy send handle script
ns_proxy wait handle ?timeout?
_________________________________________________________________
DESCRIPTION
This command provides a simple, robust proxy mechanism to evaluate Tcl scripts in a separate, pipe-
connected process. This approach can be useful both to isolate potentially thread-unsafe code outside
the address space of a multithreaded process such as AOLserver or to enable separation and timeout of
potentially misbehaving, long running scripts.
The command is provided by the nsproxy dynamic library which can be loaded into an interpreter via the
Tcl load command, for example:
load /usr/local/lib/libnsproxy.so
ns_proxy ...
It can also possible to load the library into all interpreters of an AOLserver virutal server by
specifying an nsproxy.so entry in the server's module config entry, for example:
ns_section ns/server/server1/modules
ns_param nsproxy nsproxy.so
When loaded, the library adds the single ns_proxy command with takes multiple options as described below.
Proxies are normally created on demand when requested and connected to the parent process via pipes used
to send scripts and receive response. The processes remain active until the parent process exits,
effectively closing all pipes to the slave processes.
ns_proxy active pool
Returns a list of all currently evaluating scripts in proxies for the given pool. The output is a
list which includes two elements, the string name of the proxy handle and the string for the
script being executed. It is also possible to view the currently evaluating scripts with the Unix
ps command as the proxy slave process re-writes it's command argument space with the request
script before evaluation and clears it after sending the result.
ns_proxy cleanup
Releases any handles from any pools currently owned by a thread. This command is intended to be
used as part of a garbage collection step at the end of a transaction. Calling this command
within AOLserver is not necessary as the module registers a trace to release all handles via the
Ns_TclRegisterTrace facility when interpreters are deallocated after a transaction, for example,
at the end of a connection.
ns_proxy config pool ?-opt val -opt val ...
Configures options for the pool specified by pool. The pool is created with default options if it
does not already exist. The result of ns_proxy config is a list of the current options in the
form -opt val -opt val .... Configurable options include:
-init script
Specifies a script to evaluate when proxies are started. This can be used to load additional
libraries and/or source script files. The default is no script.
-reinit script
Specifies a script to evaluate after being allocated and before being returned to the caller.
This can be used to re-initalizes shared state. The default is no script.
-min n
Sets the minimum number of proxy slave processes to pre-start before any allocations. This
defaults to 0 which results in on-demand start the first time proxies are requested. Setting it
to a higher number can be useful if initialization takes a significant amount of time.
-max n
Sets the maximum number of proxy slave processes. Requests for proxies beyond the maximum will
result in requesting threads waiting for existing proxies to be available instead of creating new
proxy processes. Setting this value to 0 disables the pool, causing all subsequent allocation
requests to fail immediately (currently allocated proxies, if any, remain valid).
-exec program
Specifies the filename of a slave proxy program. This defaults to nsproxy in the bin subdirectory
of the AOLserver process. It is possible to create a custom program and enter the proxy event
loop with the Ns_ProxyMain application startup routine; see the source code for details.
-getimeout ms
Specifies the maximum time to wait to allocate handles from the pool. The default is 500
milliseconds, i.e., 1/2 of a second.
-evaltimeout ms
Specifies the maximum time to wait for a script to be evaluated in a proxy. This parameter can be
overridden on a per-call basis with the optional timeout parameter to ns_proxy eval. The default
is 100 milliseconds, i.e., 1/10 of a second which assumes scripts are evaluated with minimal
delay.
-sendtimeout ms
-recvtimeout ms
Specifies the maximium time to wait to send a script and receive a result from a proxy. The
default is 100 milliseconds, i.e., 1/10 of a second which assumes minimal delay sending and
receiving reasonably sized scripts and results over the connecting pipe.
-waittimeout ms
Specifies the maximum time to wait for a proxy to exit. The wait is performed in a dedicated
reaper thread. The reaper will close the connection pipe and wait the given timeout. If the
timeout is exceeded, the reaper will send a SIGTERM signal and finally a SIGKILL signal to ensure
the process eventually exits. The default is 100 milliseconds which should be ample time for a
graceful exit unless the process is hung executing a very long, misbehaving script, resulting in a
more disruptive SIGTERM or SIGKILL.
ns_proxy eval handle script ?timeout?
Evalutes script in the proxy specified by handle. The optional timeout argument specifies a
maximum number of milliseconds to wait for the command to complete before raising an error (see
ERROR HANDLING below for details on handling errors).
ns_proxy send handle script
Sends script in the proxy specified by handle. Unlike with ns_proxy eval, this option will return
immediately while the script continues to execute in the proxy process. A later ns_proxy wait
followed by an ns_proxy recv is expected.
ns_proxy wait handle ?timeout?
Waits for a script sent via ns_proxy send in the proxy specified by the handle argument to
complete. The optional timeout parameter specifies the number of milliseconds to wait for the
script to complete, the default is an indefinite wait.
ns_proxy recv handle
Receives a response from a script that was sent via ns_proxy send and waited on via ns_proxy wait.
ns_proxy get pool ?-handle n -timeout ms? Returns one or
more handles to proxies from the specified pool. The pool will be created with default options if
it does not already exist. The optional -handle n arguments can be used to specify the number of
handles to allocate, the default being 1. The optional -timeout ms arguments specifies the
maximum amount of time in milliseconds to wait for the handles to become availale before raising
an error (see ERROR HANDLING below for details on handling errors). Requesting more than one
handle in a single call if more than one handle is required is necessary as it is an error to
request handles from a pool from which handles are already owned in the thread. This restriction
is to avoid a possible deadlock condition and is similar to the manner in which the ns_db
gethandles command operates.
ns_proxy ping handle
This command sends a null request to the proxy specified by the handle argument. The proxy will
be verified alive and restarted if necessary. This command is not normally required as the
ns_proxy eval command will also verify and restart proxies as needed.
ns_proxy release handle
This command can be used to release a single proxy specified by the handle argument. All handles
owned by a thread to the cooresponding pool must be returned before any handles can be allocated
again. Within AOLserver, a call to this routine is recommended for clarity but not stricting
necessary. As described above, AOLserver installs a trace to release all handles at the end of
every connection during interprepter deallocation.
ERROR HANDLING
Errors generated by a script evaluated in a proxy interpreter are completely returned to the calling
interpreter, including mapping the errorInfo and errorInfo global variables from the proxy to the parent
if present and raising a Tcl exception. This enables proxy code to look very similar to that which may
use the internal eval command.
Errors raised by a failure to communicate with the proxy process due to a timeout or unexpected process
exit are also communicated back to the parent interpreter as Tcl exceptions. To distinguish between
these cases, communication related errors set the errorCode global variable with the first element
NSPROXY. The second element is one of the following:
EDeadlock
The interpreter attempted to allocate handles from a pool from which it already owns one or more
handles.
EExec The slave program specified by the -exec program option could not be started.
ERange Insufficient handles available in pool.
ERecv There was an error receiving the result from the slave process.
ESend There was an error sending the script to the slave process.
ETimeout
The timeout specified for the pool by the -evaltimeout option or as the optional argument to the
current call to ns_proxy eval was exceeded.
EXAMPLES
The following demonstrates sending a script to a remote proxy:
set handle [ns_proxy get myproxy]
ns_proxy eval $handle {info patchlevel}
ns_proxy release $handle
The following demonstrates an asyncronous request:
set handle [ns_proxy get myproxy]
ns_proxy send $handle {long running script}
... continue other work ...
ns_proxy wait $handle
set result [ns_proxy recv $handle]
ns_proxy release $handle
The following demonstrates using multiple proxies:
ns_proxy config myproxy -max 10
set handles [ns_proxy get myproxy -handle 10]
foreach h $handles {
ns_proxy eval $h {puts "alive: [pid]"}
}
ns_proxy cleanup
SEE ALSO
eval(n)
KEYWORDS
threads, interpreters, proxy, initialization