Threads and Sockets (Was Ho hum)

[Jeff Kesselman]

Um....

You shouldnt be crashing out processes unless you have bad code or a toally
scrod OS.  Proper definesive programmigjn shoudl handle errors gracefully.

I shudder at the diea thatw e accept code crashing as "normal" or even
aceptable behavior.

JK

At 02:19 PM 4/14/97 -0400, you wrote:
>
>just a thought that someone got stuck in my head.
>
>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).
>
>As I sed, just a thought.  ;)
>
>-Greg
>
>