Introduction

OpenSimulator is an extremely concurrent application. It uses a large number of threads in

1. Persistent control loops (such as scene processing and inbound packet processing)
2. Thread pools for shorter-lived processing (e.g. for handling many viewer requests or for processing script events).
3. Runtime created threads for inbound processing (e.g. for passing UDP/HTTP data to OpenSimulator code).
4. Timer events, such as that triggered to processing statical information to send to viewers (server frames per second, etc).

Persistent control loops

Thread pools

General thread pool

By default, OpenSimulator uses a library known as the SmartThreadPool for thread pooling. One instance of this handles general server operations, such as viewer request processing. This is used across all regions hosted by that simulator.

You can see information on thread thread pool using the "show threads" command on the simulator console. It's also shown in the summary information logged by the simulator every 60 minutes.

Here is some example output.

Main threadpool (excluding script engine pools)
Thread pool used           : SmartThreadPool
Max threads                : 150
Min threads                : 2
Allocated threads          : 2
In use threads             : 0
Work items waiting         : 0

• Max threads - The maximum number of threads that will be used by this pool. If this limit is reached then further requests will have to wait for a thread to be returned to the pool.
• Min threads - The minimum number of threads that this pool will keep on hand even if no work is being performed.
• Allocated threads - The number of threads currently in the pool.
• In use threads - The number of threads currently performing tasks.
• Work items waiting - The number of work items waiting for another thread pool thread to become available.

XEngine thread pools

Each XEngine script engine will use an additional SmartThreadPool instance for its own internal operations, such as script event processing. As there is one XEngine script engine per region, this will also mean an additional thread pool per region.

Status of xengine thread pools can be seen by using the "xengine status" command on the simulator console. Here is some example output.

Status of XEngine instance for MyRegion1
Scripts loaded             : 2491
Unique scripts             : 842
Scripts waiting for load   : 0
Max threads                : 100
Min threads                : 2
Allocated threads          : 36
In use threads             : 18
Work items waiting         : 0
Sensors                    : 11
Dataserver requests        : 0
Timers                     : 36
Listeners                  : 59

Status of XEngine instance for MyRegion2
Scripts loaded             : 0
Unique scripts             : 0
Scripts waiting for load   : 0
Max threads                : 100
Min threads                : 2
Allocated threads          : 3
In use threads             : 2
Work items waiting         : 0
Sensors                    : 0
Dataserver requests        : 0
Timers                     : 0
Listeners                  : 0

In this case there are two regions, MyRegion1 and MyRegion2, and hence two thread pools. The thread pool details are the lines which match the data given for the general thread pool (Unique scripts, allocated threads, etc.). In this case, the "xengine status" command also shows additional details (scripts loaded, sensors, etc.) which are not directly thread related.

Persistent threads