On Mon, 20 Apr 1998, James Turner wrote:
>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.
Imagine throwing out all of the state stuff, dumping the current game_loop,
and running a huge amount of mobs every half second without lag. You could
do as much as you wanted and there would be no lag in cycling back to the
person. Sort of like having two processors to handle more processes, we'd
have more threads to handle more people seemingly at the same time.
>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?
pthreads is all I'd support. If you don't have POSIX threads, tough, use
the non-threaded version which would be included in the same base and also
supported.
>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.
There is a CVS, but it's not publically accessible that I know of.
>Who is in charge of the official distribution? I'm assuming he is -- am I
>mistaken?
Jeremy is, I only do bugs and trivial things at the moment.
>> 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.
#define GET_NAME(ch) getName(ch)
char *getName(struct char_data *ch)
{
[blah]
}
Of course, now 'GET_NAME(ch) = NULL;' doesn't work.
But it wouldn't work with your non-macro version either. This is of
course, avoiding C++.
>> 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
But we're not using C++.
>> 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.
Reminds me of 'register'....
>> 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.
There is also a reason the compiler picks functions to inline. I've heard
GCC will inline things very liberally, some up to 200 lines of code.
>> >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?
#define GET_STR(ch) (str_app_index[ch->str].tohit)
Or you layer further down, just like functions do.
>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());
Contrived example, in your case you'd either use a function or make a
smarter macro.
>and the con of the one after that. Contrived example somewhat, but
>macros have their limits, George. They are headaches to maintain and
As I just said, but macros are not evil and functions are not god.
>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
Sort of like typing 'ch->id' will crash when 'ch' is NULL.
>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).
Um, if you see something that crashed on a line:
strcmp(GET_NAME(ch), "bob")
and 'ch' is NULL, what is the difference?
>> 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
So are those kinds of 'if' statements, but you don't seem against those.
>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.
The way you imply we'd be doing redundancy checks upon redundancy checks.
>Probably not... but the question is, what is the criterion for
>something getting into stock code? A lot of people like clans. A lot
The answer to that is: "Ask Jeremy."
--
George Greer - Me@Null.net | Genius may have its limitations, but stupidity
http://www.van.ml.org/~greerga | is not thus handicapped. -- Elbert Hubbard
+------------------------------------------------------------+
| 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