13.9 Using Cheetah in a Multi-Threaded Application

Template classes may be shared freely between threads. However, template instances should not be shared unless you either:

Use a lock (mutex) to serialize template fills, to prevent two threads from filling the template at the same time.
Avoid thread-unsafe features:
- Modifying searchList values or instance variables.
- Caching ($*var, #cache, etc).
- #set global, #filter, #errorCatcher.
Any changes to these in one thread will be visible in other threads, causing them to give inconsistent output.

About the only advantage in sharing a template instance is building up the placeholder cache. But template instances are so low overhead that it probably wouldn't take perceptibly longer to let each thread instantiate its own template instance. Only if you're filling templates several times a second would the time difference be significant, or if some of the placeholders trigger extremely slow calculations (e.g., parsing a long text file each time). The biggest overhead in Cheetah is importing the Template module in the first place, but that has to be done only once in a long-running application.

You can use Python's mutex module for the lock, or any similar mutex. If you have to change searchList values or instance variables before each fill (which is usually the case), lock the mutex before doing this, and unlock it only after the fill is complete.

For Webware servlets, you're probably better off using Webware's servlet caching rather than Cheetah's caching. Don't override the servlet's .canBeThreaded() method unless you avoid the unsafe operations listed above.