George <greerga@CIRCLEMUD.ORG> writes:
> >The problem in this though is that you have incredibly annoying
> >synchronization issues. Moreover, you can never guarantee, short of
> >using huge mutex locks all over the code, than a valid target on line
> >X will be valid on line Y. Also, synchronization of fights is an
>
> You simply #define the function calls out of existance if you're not using
> pthreads.
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.
> >issue. And unless some kind of slowdown is put on command execution,
> >players with faster links will be able to do more commands than those
> >with slower (as opposed to the current one command per player per pass
> >in the main loop).
>
> There wouldn't be a difference based on your link more than there already
> is.
Unless you keep me from issuing a command more than X times per second
there will be. Someone local could blast 500 "n" commands to the mud
and be there as fast as their link will take them. It just adds to
the inequity of link speed (something we can't and shouldn't let hinder
development completely, but it _IS_ something that should be taken
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 messy. It would fundamentally change the code; supporting two
> >versions wouldn't be nearly as easy as now, and just about every
> >snippet would need a threads version and a non threads version.
>
> You're the one that hates ASPELL/CREATE/etc and you're lecturing me on
> messy?
There's a difference between messy style and messy design. You think
expanding the ACMDs would be trouble maintaining, I can guarantee you
that the multithreaded code will be a hundred times worse, even if
it's so filled with mutexes that it practically is serialized anyway.
> >Things like GET_NAME(ch) = p, GET_STR(ch) = 10, etc., are bad as-is.
> >There is no assurance that data assigned is valid. setName,
> >setStrength, etc would be better ways to assign these.
>
> Um, as I said previously, you want redundancy upon redundancy.
> The code already checks what it is assigned to make sure it is valid.
> If something slips by then you fix that section of code. C doesn't need
> such Big Brother checking unless you cannot write a decent function.
> If something is extremely redundant like GET_ROOM_VNUM(), then add it to
> the macro or just write a function for it. But not everything needs it.
No, I want redundancy when it matters. Not everything requires it,
but a lot could definitely use it.
> >gcc is picky, and stubborn, and somewhat obstinate sometimes, and
> >inlining is one. It is rather ad hoc about it.
>
> I do believe we're writing a MUD here, not exactly a speed-critical server
> that requires inline functions. Anything that speeds it up without much
> trouble is fine but inline functions do not fit in that category
> (especially since they don't work when you define -ansi).
Indeed, it is a mud, and you're right, speed isn't a huge issue. But
my point is that speed isn't an issue for not using macros, since the
same speed can be achieved through inlining when necessary.
> >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,
then email is a more proper place -- I have no desire to turn this
list into a place for such things, as I'm sure you don't. Otherwise,
don't bother replying. No one is forcing you to. However, you'll
find there are a lot of valid ideas out there if you'll just be
willing to accept that there are other ways to do it than the current
code handles them.
> It crashed, so by the context of the code you can tell what is NULL.
>
> if (GET_IDNUM(ch) > 0)
> if (!str_cmp(GET_NAME(ch), "Bob"))
>
> You can tell 'ch' is not NULL, so ch->name must be.
>
> And if you cannot tell which is NULL, add a check against both!
Indeed, in many cases, context can tell what is going on. But using
functions, it's more clear, as well as having possible recoveries when
there is a problem.
> >Redundancy can be good. Error checking is better. I'd rather my
> >player files not get corrupt by errant pointers or whatnot. NULL
> >pointers won't do this, but invalid pointers can. It is dangerous to
> >always assume pointers are valid (and non-null pointers can be checked
> >for validity with, say, magic bytes).
>
> Then manage your pointers better. Random pointers can still cause a crash,
> corruption or other mischief, even with trying magic bytes.
>
> You may get unlucky and the same memory gets reused...etc
> (I've seen it.)
Pointer management is wonderful, fantastic, but not everyone can do it
perfectly. Code that crashes when it could otherwise recover is
sloppy. Circle should be a clean, reliable codebase that crashes as
little as possible -- even when the person adding code isn't the best
programmer in the world. Like it or not, a lot of people use circle
as a way to learn C or improve their coding skills.
> >Using assert() and defining DEBUG and such would take care of the
> >performance issue on production builds.
>
> 'production'? I'd say most MUD's keep debugging info for unexpected
> crashes and don't have to worry about performance.
If speed isn't the issue, what exactly is your objection to redundance
when it could avoid corruption and crashes?
--
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