Following options are supported:
The idle worker thread is not servicing the event loop . If you, however, put the worker thread into the event loop, by evaluating the vwait or other related Tcl commands, the worker thread will not be in the idle state, hence the idle timer will not be taken into account . Default value for this option is unspecified .
The command returns the ID of the posted job . This ID is used for subsequent tpool::wait, tpool::get and tpool::cancel commands to wait for and retrieve result of the posted script, or cancel the posted job respectively . If the optional ?-detached? argument is specified, the command will post a detached job . A detached job can not be cancelled or waited upon and is not identified by the job ID .
If the threadpool tpool is not found in the list of active thread pools, the command will throw error . The error will also be triggered if the newly created worker thread fails to initialize .
The command returns the list of completed job IDs . If the optional variable ?varname? is given, it will be set to the list of jobs in the joblist which are still pending . If the threadpool tpool is not found in the list of active thread pools, the command will throw error .
A thread pool offers a solution to both the problem of thread life-cycle overhead and the problem of resource trashing . By reusing threads for multiple tasks, the thread-creation overhead is spread over many tasks . As a bonus, because the thread already exists when a request arrives, the delay introduced by thread creation is eliminated . Thus, the request can be serviced immediately . Furthermore, by properly tuning the number of threads in the thread pool, resource thrashing may also be eliminated by forcing any request to wait until a thread is available to process it .