[Home] [Groups] - Message: [Prev in Group] [Next in Group]

nu.kanga.list.mud-dev

8574: [MUD-Dev] Re: PDMud thread summary

[Full Header] [Plain Text]
From: Jon Leonard <jleonard@divcom.slimy.com>
Newsgroups: nu.kanga.list.mud-dev
Date: Fri, 23 Oct 1998 14:37:04 -0700
References: [1] [2] [3] [4] [5] [6] <-newest
Organization: Kanga.Nu
On Fri, Oct 23, 1998 at 09:38:30PM +0100, Jo Dillon wrote:
> Jon Leonard (jleonard@divcom.slimy.com) spake thusly:
> > 
> > There really aren't that many OS features that a MUD needs to use, and with
> > a modular design, these can often be isolated.
> > 
> > I think the only things that all modules would have to be aware of are
> > dynamic linking and threads.  There should be compile time options to
> > turn those off, too.  (My old computer supports neither, for example.)
> >
>   Threads tend to be an all-or-nothing thing; it's hard to just
> 'switch them off' :)

Indeed.  'Switching off threads' may well involve making a large number of
modules unavailable.  But if threads aren't going to be used, this can be
specified at compile time to get much cheaper mutexes.

It should also be possible to mix thread-unsafe and threaded modules in the
same server by using a monitor to serialize access to the unsafe portions.
 
>   Threads and sockets should definitely be abstracted IMHO; I've got
> a thin blocking socket and threads wrapper somewhere.

Sockets should be fairly easy to abstract.  The only catch is that in a
single-threaded server, the call to select() needs to be aware of all
timing requirements and non-blocking IO, which may include more than
just the telnet sockets.  In such a server, the socket module should
probably export all of it's file descriptor information to a timer module.
Any X clients or other wierd IO modules should do the same.

Since thread-safety (and MP safety) are global properties, they're much
harder to abstract.

Jon Leonard