Threadname

Thread Names

Overview

The "tools/threadname/" directory contains a small library for setting thread names. Naming the threads is useful when you see the "top" or "htop" utility output and want to see what threads eat the most CPU in your project. The first place will be taken by the game logic and slave client threads but usually what's interesting is what is on the second place. You can correlate the CPU core usage percentage with the number of active clients. All of the threads in the Snipe server core are named using this library but you might create some more threads in your project (or make some multi-threaded tool) and have proper names for them.

List of Snipe server thread names

Many of these names will be seen multiple times in the output of Linux "top" or "htop" command for one of two reasons - either they belong to different logical servers or they belong to a pool of similar threads.

Name	Logical server type	Description
<server name>	Cache	Connected and logged in slave client thread. All requests from that slave server will be handled in that thread. The server name is taken from server configuration file.
async worker	Cache	Asynchronous worker thread. Described in [[Asynchronous Worker
async: <X>	Slave	Asynchronous worker thread. Described in [[Worker
asyncDB <X>	Cache	Asynchronous database manager thread. Described in [[Asynchronous Database Manager
autosave	Cache	Autosave manager thread. Described in [[Autosave Manager
cache init	Cache	Initialization thread (uniserver mode).
cache read	Slave	Cache server connection reading thread.
cache write	Slave	Cache server connection reading thread.
database write	Cache	Data blocks cache writer thread.
timer cache	Cache	Timer thread. Described in the [[Timers
timer <server type>	Slave	Timer thread. Described in the [[Timers
logger: cache	Cache	Logger thread. Described in the [[Logger
logger: <server type>	Slave	Logger thread. Described in the [[Logger
logger: <name>	Cache or slave	Custom logger thread. Described in the [[Logger
pending	Cache	Cache server pending SQL queries thread.
sender: <letter>.<number>	Slave	Client responses sender thread. The letter is the first letter of server type, the number is the thread number in pool.
serializer: <letter>.<number>	Slave	Client responses serializer thread. The letter is the first letter of server type, the number is the thread number in pool.
slave <server type> init	Slave	Initialization thread (uniserver mode).
socket pool	Slave	Client connections socket pool.
old worker	Cache	Haxe ThreadServer worker thread. Used only by ThreadServer internals.
timer	Slave	Haxe ThreadServer timer thread. Used to disconnect clients that are inactive for 3 minutes.
url: <letter>.<number>:<number>	Slave	HTTP requests handler (snipe.slave.URLRequester class). The letter is the first letter of server type, the first number is the main worker thread number in meta-server pool, the second number is handler thread number in pool.
worker cache	Cache	Vacant slave client thread. Will be renamed to server name when the slave server logs in. Might also be used by the editor, or some local script that connects to cache server.
worker: <letter>.<number>	Slave	Slave server logic thread. The letter is the first letter of server type, the number is the thread number in pool.
worker: main	Slave	Haxe ThreadServer main thread. Used by the ThreadServer internals.

Using the library

The first thing you need to do is to include the class path for "ThreadName.hx" in your .hxml file. The class itself contains a single method: ThreadName.set(). It acceps a single argument - the thread name. Note that Linux pthreads library only allows thread names of up to 15 symbols long. The method will truncate the string if it's too long.

The Snipe server core includes a compiled 64-bit Neko DLL file for the library and the source code to compile 32-bit version if you need it. The compiled DLL file should be either in the same directory as the Neko file you're trying to interpret or in the global Neko library directory ("/usr/lib/neko" by default).