Threads and Sockets (Was Ho hum)
jeffk at tenetwork.com
Mon Apr 14 20:12:58 New Zealand Standard Time 1997
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
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
>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. ;)
More information about the MUD-Dev