George <greerga@CIRCLEMUD.ORG> writes:
> >The archetecture is too complicated for that. You can't just define
> >out the thread creation calls. Too much other code needs changed.
> >And there is still the issue of the need to use quite a bit of mutex
> >locking -- which effectively serializes the code.
>
> No, code like the creation would remain in a separate function but all the
> locking functions could be eliminated.
The design wouldn't work. There's no reason to give every player
their own thread; that's not necessary. Perhaps one thread for input,
one for dispatching commands, one for zone resetting. But one per
player is definitely overkill -- the current archetecture works quite
well, and it isn't very CPU intensive... in fact, there's no way that
threading would end up using less CPU time. It messes up locality,
causes context switches (cheaper than switching processes, but not
negligible), as well as adding mutual exclusion overhead.
> You can type just as fast on a slow link, your commands just get 'clumped'
> together.
Slow faucets don't always drop. Some just have small openings. Same
with bandwidth. It isn't just a clumping issue.
> >into account). Further, someone could monopolize resources by
> >spamming high CPU use functions, and it wouldn't be immediately clear
> >from the cause.
>
> It's not hard to delay, or limit the commands if deemed necessary for
> that purpose, many MUD's I have seen check for spamming commands. But
> delay isn't necessarily needed for link conditions.
It just adds to the problem, though, of people burning CPU time.
Since their commands will be desynchronized from everyone else's, they
can blaze ahead and eat CPU time.
> >> >There's no check to see if ch's str is valid, or if ch is a valid
> >> >pointer, etc etc etc. Macros are bad.
> >>
> >> ch->id = 1;
> >>
> >> There's no check to see if ch is valid or 1 can be assigned to it.
> >> C assignment statements are bad.
> >
> >You're being asinine. If you wish to have a discussion without
> >knee-jerk reactions, then let's do so. If you wish to be insulting,
>
> I'm taking your argument to the extreme to show its absurdity. I
> apologize that you thought I was insulting you.
The argument isn't absurd. Are you saying that there is no need for
argument validation in a robust system?
> >If speed isn't the issue, what exactly is your objection to redundance
> >when it could avoid corruption and crashes?
>
> There's no point in checking if a variable is within limits three times,
> irregardless of speed issues.
>
> #define LIMIT(var, min, max) (MAX(min, MIN(var, max)))
>
> GET_STR(ch) = LIMIT(new_strength, 3, 18);
>
> Simple, within limits, and easily circumvented if you don't need the check.
> You don't need to check once in the function, and another time when the
> assignment function executes. The argument for limits doesn't apply for
> strings, where everything should check for a NULL pointer. Your careful
> checking may be destroyed by a memory overrun anyway, in which case your
> check upon assignment won't help there.
But then you have to put the limit in every time you set the char's
strength. If something says get, it is implied it gives a value.
Since C can't give references, this obfuscates the role of GET_*.
Allowing code to assign STR too high can result later in overruns in
references to the lookup tables. Then, when that happens, it isn't
trivial to find out what assignment made the STR too large. But
having a setStrength function would take care of that in short order,
eliminating the risk (though not the large assignment, which could
produce a runtime warning, as opposed to a crash at some vague later
point).
--
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