George <greerga@CIRCLEMUD.ORG> writes:
> >Definitely, though I don't know how necessary or useful multithreading
> >would be... like changing to C++, it isn't something we should do
> >midstream unless there is hugely compelling need. But that horrid
> >global variable buf needs killing! :)
>
> The example Jeremy gave was to have one thread for each person. That would
> eliminate 'lag' from commands which take forever, prevent infinite loops
> from affecting everyone, and allow the use of blocking socket I/O.
Threading like this would be a huge break from the standard mud model
(ie, the way input is handled and so forth). Major architectural
changes. The question is, why? Threads are nice, but they're not
going to magically solve all our problems. In fact, quite the
opposite, synchronization will add quite a number of them. No command
should take more than the blink of an eye -- if it does, there is a
problem somewhere else. Even the track code, which does a graph
search on a _huge_ directed graph (ie the rooms), doesn't lag the mud
noticeably, even when logged in local.
Further, if you read some on the Mozilla project, you see that
Netscape had to write their own threading library from scratch to sit
on top of all other OS's threads. Is that something that really needs
doing in stock code?
> >Can you clear me up, and perhaps others at the same time? What are
>
> 3.0 won't get anything new except AutoEQ (bpl14) and alias saving (TBA).
Something I'm somewhat unclear on is who has the say on what goes in
where, and when things move along. Jeremy mentioned opening Circle up
like a Bazaar-style development, and said something about a CVS
repository, but I never saw any followups to that. Who is in charge
of the official distribution? I'm assuming he is -- am I mistaken?
> >Macros are hideous :) We should replace them with functions. I
> >wasn't suggesting we do things like ch->name; we should have
> >
> >const char *getName(CHAR_DATA *ch);
>
> Uh, why? If you want that, run 's/GET_NAME/getName/g'.
>
> Macros are meant to be indistinguishable from functions.
Indistinguishable, yes. But not an ubiquitous replacement. The
reason for why is, suppose later someone wants to add code to let
people disguise and answer to different names. A macro makes this
harder, and flow control less clear. A function makes it very easy to
follow. The macros work right now, but they're bulging at the seams.
They've been pushed too far, and are costing the Circle codebase a
great deal in terms of expandibility as well as readability.
> What kind of flow control would a data access macro need to do besides
> limited array bounds checks? (Do not argue about NULL checking.)
>
> CAN_SEE() gets unwieldly but can still be followed.
>
> There are also things macros may do which functions may not. (Like say, a
> short_description macro which works for both mobs and objects.)
Not true, as I showed in a different post. We can use weak
inheritance to get the same effect as macros. Further, we get
typechecking when appropriate. GET_NAME(obj) or GET_LEVEL(room) don't
make sense, yet the compiler, instead of spitting out an error about
invalid types, will complain about there not being certain fields in
certain types.
Also, the visibility macros (part of CAN_SEE) are a mess. This all
needs fixing -- it makes it harder to maintain, and harder for new coders.
> >As I mentioned in my response to another message, we need to be able
> >to explicitly dictate which functions get inline'd. gcc is smart, but
>
> Just because you declare it 'inline,' doesn't mean it will be.
I know, but it gives the compiler further help in picking what to
inline. And it's a lot better of an assurance than hoping -O3 picks
the right functions on its own.
> >it can't properly predict the flow graphs of code once it is actually
> >executed. Also, it won't inline every function -- that would make a
> >HUGE executable. It tried to pick and choose; we should help it.
>
> You cannot inline every function.
That was my point -- inlining every function won't work. We should
help the compiler pick what functions to inline instead of relying on
its own algorithms. That's what the inline keyword is for.
> >Those kinds of things. It makes it easy to add or remove abilities,
> >as well as using a uniform interface to fundamental abilities (ie the
> >ones stock has now) and derived abilities (say we want an ability
> >based partially on strength and endurance).
>
> #define GET_STR(ch) ((GET_DEX(ch) + GET_CON(ch)) / 2)
What if it involves a table lookup?
Also, this has a problem. If ch isn't a simple variable, a function
will be called twice. For instance, suppose nextSpellVictim returns
the next victim of a spell in a given room.
GET_STR(nextSpellVictim());
That won't work, because it will get the dex of the next victim,
and the con of the one after that. Contrived example somewhat, but
macros have their limits, George. They are headaches to maintain and
expand. They make it harder to see exactly what the problem is (how
many times have people posted gdb traces here where the error was
GET_NAME(vict) with vict being NULL? It's not immediately clear to
them that a memory reference to NULL took place. If GET_NAME were a
function, the seg violation would occur at the right place inside that
function -- or better yet, in an assert() statement).
> >It does make the code a small bit wordier. However, it abstracts the
> >underlying structures as well as providing range checking and so forth.
>
> Could do that in a macro too.
Three-line macros, strung together with && and || are a headache to
maintain and deal with. There is absolutely no need in modern
computing in these cases. Circle is a mud, not a compiler, or runtime
interpreter. Speed is important, but we're not exactly burning CPU
time as-is. We can afford to spend a few more cycles for a more
robust, reliable codebase.
> >I use the word guild for what most people call clans, I believe.
> >Groups that players can divide themselves into. Allegiances, so to
> >speak. Not the guilds that stock has (ie not the 4 basic clases).
>
> Doubt you'll get that into stock code.
Probably not... but the question is, what is the criterion for
something getting into stock code? A lot of people like clans. A lot
use the various patches. An official patch, built into stock, would
a) reduce the support of 50 different versions and b) provide a chance
to make one high-quality, thoroughly checked piece of code as opposed
to half a dozen variants (that's not to say the current snippets are
bad -- quite the opposite -- but some things just belong in the code
base, and snippets inherently get less testing that stock).
--
James Turner turnerjh@xtn.net
http://www.vuse.vanderbilt.edu/~turnerj1/
+------------------------------------------------------------+
| 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/15/00 PST