[MUD-Dev] New to MUD Dev, need friendly advice!

[Byron Ellacott]

On Wed, 2003-04-30 at 23:33, Jo Dillon wrote:

> epoll() sounded like something different to me. poll() still
> requires you pass an array of fd's in every time, which is not
> highly optimised to my mind.

The difference between poll() and select() is that poll() uses an
array, and select() uses a bitmap.  The complexity of poll() is the
size of the array, but the complexity of select() depends on the
largest file descriptor.  You are right in saying this is not a
major optimization over select() :) What I should have said is that
poll() is a more scalable version of select().  /dev/epoll (and
corresponding syscalls) are certainly more efficient.  My bad.
Sorry. :)

Unfortunately, they're not really very portable. :) For example, the
MUD I do a spot of coding for is hosted on a machine out of my
control, currently running kernel 2.2.12; I can't use epoll here.
Similarly, epoll is not portable between different flavours of UNIX.
Hopefully in the near future a standard will emerge.

> Errrrr - this is what mutexes and similar mechanisms are for. I'd
> say MUDs are actually inherently parallel since you have several
> players and lots of mobiles all doing things at once (although as
> mentioned before, having a thread for each of them is most likely
> a bad idea).

Here I have to disagree.  In a MUD, it may appear that things are
parallel, but all the things being done by players and mobiles are
done in a serial queue, with a strict order.  That is, two observers
will see the same set of events in exactly the same order.

Whether you do this in a threaded system using mutexes et al, or do
this implicitly by multiplexing IO, the end result is the same.  The
two approaches each have strengths and weaknesses; I prefer
multiplexing because the complexity of highly interactive threads
requires some very careful programming, and usually some very
irritating debugging. ;)

I'd suspect threading would be more effective as the number of
connected clients increases, depending on the operating system's
capacity to handle large numbers of threads.

--
Byron Ellacott <bje at apnic.net>
APNIC

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