On Aug 18, Jeremy Elson wrote
>
> What I've been mulling over lately, actually, is an all-C++ mud using
> POSIX threads, one thread per player, with a compiled worldfile format
> more or less resembling C ... but that is such a major change that the
> MUD would probably no longer be "CircleMUD". The worldfile format
> I've been thinking of is something like:
>
An all C++ mud would be very cool. For short term, you might think about
making circle C++ clean, so it lets people start modifying it in either
C or C++. If i remember right, its just changing some variable names
(this, new, virtual, etc) and cleaning up some prototyping and externs.
Using one thread per player could be very limiting on some systems.
POSIX threads only require 64 threads per process, which would limit
the players on some platforms. Although its possible to be even more
limited by open descriptors (POSIX specifies at least 16),
the 64 thread limit is much more likely to be a problem. I remember
recently coming across at least one thread package limited at 64 threads
(by default). A model of one (or two) threads handling network I/O
and a thread handling the event queue (and maybe a thread or two
for some other things) should provide the same conceptual advantages but
with less overhead.
An integrated event system would be a major improvement to CircleMUD
(for a future project). Ticks seem so primative after playing on a
mud which makes heavy use of events.
Eric
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/08/00 PST