Network
RubIRCd features a threaded socket model (1 thread per connection) or an event-driven model. Threaded I/O works best under JRuby or Rubinius where there is no GIL (global interpreter lock.) Ruby native select() is also supported along with epoll, poll, and kqueue via Celluloid.
The advantages of the threaded model is that users can take advantage of native threading if using JRuby or Rubinius. Furthermore, the JVM that ships with JRuby supports thread pooling or thread reuse which helps cut down on the creation of new threads (creation of new threads can be expensive.) See Why Jruby? for more information. Writing code is also simpler to handle each client. Lastly, since each client has its own thread, calls that block would not block the entire process. The disadvantages to this model are:
- New threads are expensive to create
- Killed off threads can be a waste
- May be more resource intensive with a lot of simultaneous connections
- Synchronization with the use of mutexes and semaphores may be required to defend against race conditions
- Potential to introduce dirty reads/writes and deadlocks
The advantages of the event-driven model (epoll, kqueue, poll, select) are:
- High performance
- One single process/no new thread for every client
- No synchronization required
The disadvantages are:
- Code may be more difficult to write to handle client connections
- Calls that block may block the entire server process
- Not as hip/cool as threads ;)