Threads and Sockets (Was Ho hum)

[Chris Gray]

[Greg:]
:I know threads are less expensive than full process switching, but isn't using
:threads of the main program for handling I/O kinda dangerous?	If the sockets
:or any I/O bombs, down comes the whole program, or if the program goes down,
:everyone gets dropped from the game.  I've been leaning towards a
:multi-processesing, multi-threaded environment where *most* of the mechanics
:are grouped into one process that is threaded and all the file I/O and socket
:Handling is done with other processes (possibly also threaded).  That way, if
:one process crashes the rest can keep plugging along or (in the case of the
:game crashing and the socket process still running) tell the players that the
:mud is experienceing technical difficulties (after some timeout period
:expires).  I use the message queue system to communicate among the processes,
:mainly because it lends itself nicely to an event driven system and packaging
:commands and info into discrete units (which I prefer to deal with).

Threads can be fairly cheap, since they share the virtual address space,
and so can communicate quickly. With separate processes, however, it
generally takes a system call or two to safely communicate between them.
You *can* use things like spin-locks in shared memory regions/segments,
but you have to be careful, and be prepared for the occasional very
inappropriate time slice from the OS.

System calls are the bane of the parallel processing stuff we do at work,
as are process switches. We stand on one leg and wiggle our ears in order
to reduce the numbers of both :-)

--
Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA