[MUD-Dev] Re: PDMud thread summary
jleonard at divcom.slimy.com
Fri Oct 23 14:37:04 New Zealand Daylight Time 1998
On Fri, Oct 23, 1998 at 09:38:30PM +0100, Jo Dillon wrote:
> Jon Leonard (jleonard at 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.
More information about the MUD-Dev