Prolix is designed to be a fairly simple bot with a few exceptions. The threading model to Prolix is certainly one of those exceptions.

There are several different possible threading approaches:

• Single Thread - Nonblocking
  A single task without threads and completly non-blocking is a very efficient solution. zDSBot3 was like this, as the only thing that blocked was the DNS lookups. thttpd is a webserver that uses this same method.
• Thread per Bot
  This is actually a fairly decent solution. It is easy to implement, and keeps one bot from interfering with another bot. This model obviously has problems when using a large number of bots, as each bot gets it's own thread. This can be cleaned up so the bot runs some number n threads per thread.
• Thread per System
  This is a interesting approach as each "system" (ex: saving/networking/dns) runs in it's own thread. This model involves some overhead as messages must be passed between each thread, for example - the bot would like to send a packet, so it must pass the packet to the network thread.

zDSBot3 uses the first model, and there are several windows bots that use the second model. Prolix uses the third model (which fits well with the name).

Master Thread

The "master thread" or the initial thread the program starts up on is responsible for starting all the other threads. When prolix closes, the master thread waits for all threads to be finished.

  init all threads
  wait for mutex_quit
  wait for all threads to quit

Bot Thread

The Bot Thread runs ALL of the bots in it. In the future each bot module will be ran in it's own thread, but multiple bots of the same bot module will exist in the same thread.

The bot thread calls the handler for each individual bot. Each bot in turn checks to see if it has any packets waiting.

  wait for mutex or timeout
    if mutex bothandler
    if idletime botidlehandler

Net - isConnected, isConnecting, Connect (All non-blocking)

  poll
    if signal
      handleCommanQueue();
    if ISSET( net[i]->fd)
      net[i]->handler();
  

DNS

// getIP - 0 ok, -1 busy, -2 unable to resolve

  if mutex
    lookup host

Config (handles all database related saving)

  wait for mutex
    load/save

The Log Thread The log thread (short of the main thread) is the simplest thread in prolix. The log thread takes simple messages and appends them to a disk file in it's own leisure. The log thread is capable of handling multiple different log files at once. This allows for different modules to use seperate log files as they choose. The actual enqueue is done in the thread of the log caller, and then is written to disk in the log thread.

Auth Thread The auth thread handles all of the time consuming aspects of the auth equation. This consists of a couple million math operations per login.

Display