[MUD-Dev] Socket Code

[Smith]

Stephen Miller wrote:

> So the basic gist of this system would be to have a thread for
> each connection which has a blocking select.  Each time the select
> receives input on its socket, it grabs the input and if it should
> have a line, it will lock (through semaphores or mutexes) the
> respective shared memory player queue and push the new line onto
> the back of the queue.  Then it unlocks and blocks again for more
> input.

The first, best piece of advice that I possibly have is "check out
the ACE library". You can find it at

  http://www.cs.wustl.edu/~schmidt/ACE.html

In brief, it's a cross-platform communications library in C++ with
strong support for socket communications and multithreading.

But aside from the library (and documentation surrounding it), there
are some strong negatives that you'd get with the third method
above, namely thread overhead, working with user-space threads,
ideally, you want to use just many enough threads so that you
maximize processor use (at least one per processor), and so that you
minimize context switching (~= at most one per processor).

The best possible solution (likely), would be to use Posix's AIO
mechanisms; however, this is probably also the hardest to
code. Without AIO, using a thread-pool reactor (the reactor is a
design pattern for event dispatching, and an implementation exists
in the ACE library that is easily used) is likely the best solution,
the thread pool delegates a thread at a time to perform the
underlying select call, then that thread is used (no context switch)
to dispatch/handle the socket event. A thread from the thread pool
then resumes the role as leader and calls select on the fd_set, this
minimizes the time that threads spend in select, minimizes the
number of context switches, and comes close to maximizing throughput
by tuning the number of threads available to the
thread-pool. Nicely, if the thread pool size is too large, the
remaining threads are never unblocked, so context switching is still
minimized.

<sighs> My un-caffeinated brain truly just produced a bunch of
almost unreadable prose there, sorry about that.

A much clearer overview of the reactor pattern can be found:

  http://www.cs.wustl.edu/~schmidt/PDF/reactor-siemens.pdf

Happy hunting, and even happier multithreading

-dave

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev