[MUD-Dev] TECH: Single process v.s. multi process?

[Bruce Mitchener]

Philip Mak wrote:

> As I understand it, when building a MUSH codebase from scratch, I
> can do it one of three ways:

>   (1) Single process: A single process that listens for player
>   connections on a TCP port and handles everything.

...

> I'm only familiar with #1 from my experience with PennMUSH. One of
> the problems with #1 is that it's hard to defend against malicious
> softcode that consumes too much resources. For example, if I input
> a complicated command with many function evaluations, it will lock
> up the whole MUSH for several seconds. If I manage to generate a
> stack overflow, it will crash the whole MUSH. (It's trivial to
> crash any PennMUSH in three commands, except those running
> 1.7.5p5+ with call_limit enabled.)

Cold and MOO handle this by tracking the number of operations that a
task executes and having a max number of operations that can be
executed without having a re-schedule to allow other tasks to run.

But, in computer science, there's a lot of interesting work in the
field of 'Communicating Sequential Systems' (CSP) that is very
relevant for this type of problem.

A good set of links to get you started can be found at the CSP
Archive:

   http://www.afm.sbu.ac.uk/csp/

or in foldoc:

 http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?Communicating+Sequential+Processes

of this old (short) thread on Lambda the Ultimate:

   http://lambda.weblogs.com/discuss/msgReader$29

CSP was the basis of the tasking model in the Ada programming language:

   http://archive.adaic.com/standards/83rat/html/ratl-13-03.html

An implementation exists for Java:

   http://www.cs.ukc.ac.uk/projects/ofa/jcsp/

There's a confernece on this sort of thing later this year:

   http://www.wotug.org/cpa2002/

There's also an implementation for the C programming language:

   http://www.quickstone.com/ccsp/

The Limbo language also used these concepts:

   http://www.vitanuova.com/inferno/papers/descent.html

Stackless Python is also using concepts from Limbo and will be 
implementing Hoare's CSP:

   http://www.stackless.com/

A more general overview of high-level concurrent programming is given on:

   http://www.ps.uni-sb.de/~mmueller/events/hlcl-2.html

Erlang implements this sort of model as well (as noted previously
here on MUD-Dev within the last month):

   http://www.erlang.org/

Also of interest given discussion years ago about trying to avoid
deadlocks in a mud server that used threads is the work that has
been done with these systems to prove an absence of deadlocks.

   http://www.erlang.se/publications/xjobb/0108-carlsson.ps.gz

      "Abstract: We argue that there is a need for automated
      verification of absence of deadlocks in concurrent
      programs. We briefly describe how absence of deadlocks can be
      showed, in general, for a program, how the necessary
      information can be gathered, and the use of formal methods. We
      discuss timeouts as a method of run-time deadlock detection,
      and why they remain necessary in some situations, and we
      suggest a strategy for modular verification of subsystems of
      concurrent programs.

      We then give an overview of the area of process communication,
      nondeterminism, and synchronization problems, with focus on
      the semantics of Erlang, and give a quick introduction to the
      Erlang language.  We give detailed models of the semantics of
      the Erlang messaging system and its synchronization primitives
      both in terms of synchronously communicating sequential
      processes and of Concurrent Constraint Programming.

      Lastly, we review a deadlock analysis method which we have
      found likely to be able to fulfil our requirements, and
      discuss the particular problems with adapting it to Erlang."

Overall, I'm inclined to think that something like CSP is far less
error prone and easier to use than a threaded or multi-process model
and depending on what you're trying to do, may well be good enough
(or superior).

Good luck!

  - Bruce

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