George <greerga@circlemud.org> writes:
> The End:
>
> I have come to the conclusion that you, my dear sir, are petty to a fault
> and reiterate the same arguments over and over. I am all in favor of making
> changes with people who will admit when they are wrong, but you shall
> never, I see.
So the value of an idea is dependant of the person who suggests it?
That's not a very effective way to promote growth, George. I am sorry
that you are unwilling to accept new ideas. I see now that your
desire is merely to patch bugs and occasionally toss in snippets,
instead of rework some of the deeper undercurrents. It is a pity;
packing features in at the sake of good design is something
proprietary software is good for. But it is certainly your and
Jeremy's choice.
It is clear now that circle would never function well under a bazaar
style development model; you clearly have no interest in letting
others become involved beyond handing in simple patches. Everyone,
myself included, appreciates the time and effort you put into circle.
But it is unfortunate that you are not willing to admit there are
flaws that could be addressed in future revisions.
This will be my last post to the list regarding any of the topics we
have already discussed. My intent in starting this thread was to
breathe some new life into circle, and to encourage some
considerations of what I felt were some serious flaws in the code.
However, though I have met with some positive responses (most through
email, something Mr. Koepke apparently cannot differentiate between
the mailing list), a good deal of them have been "me-toos" agreeing
with you, not always for the sake of your arguments, but simply
because you're George.
When I began the thread, I was interested in whether ideas would be
valued on their own merit or not. Clearly they are not, at least not
by the vocal minority on this list. It is a pity, but it is certainly
your choice.
> And if you believe I have never admitted I am wrong, I have said that:
> 1) macros have their limits, you just have to know them. As in, there are
> some cases of macros that could be functions (CAN_SEE for example)
And I have said that they do serve a purpose, but not when it comes to
ease of extension.
> 2) not everyone has as good a system as I, though some have better, and I
> do still have my 486/50 after all.
Yet you seem to think because something runs well on your system that
it will run acceptably on all others.
> 4) That speed matters when it doesn't complicate the code unnecessarily.
It matters to the point of not creating inefficiencies, certainly.
But optimizing some things at the cost of expandability is IMO not
something worth doing in a project where the majority of work done is
proprietary extensions.
> * So in the case of threads, their use would outweigh the speed penalty.
> (Of course, assuming we properly implement them so they have their full
> advantages.)
Debugging multithreaded apps are a REAL pain. Not only that, but
making the code thread-safe for non threaded versions yet fully
exploiting threads in systems that allow it will be extremely
non-trivial. There are better ways to spend time on the circle
codebase. I will be honest -- I don't question your abilities to patch
circlemud, and to do snippets; I do question your design decisions.
Putting threads into circlemud will significantly raise the bar, both
in terms of skills needed to extend/modify as well as development tool
issues.
> * ASCII pfiles far outweigh any (trivial) performance penalty.
You still never ran anything like (updatedb&; sleep 10; time autorun&)
with a flushed system cache. Disk-thrashing _is_ a significant
issue. For the most part, ascii pfiles aren't a huge performance
loss, unless you scan through each and every one at boot time; that is
ridiculous, and I believe even Sammy has said so.
> * Converting all macros to functions _does_not_ outweigh the performance
> penalty because they have scarce advantages over macros.
Not all _should_ be converted. However, the vast majority could very
much benefit in terms of future expandability.
Another reason for it that I never really brought up would be to
provide an air-tight way of preventing memory corruption. If every
write to a char_data structure went through functions, it would allow
for the following avenue.
Allocate all char_data's (and substructures/strings) from a special
block of memory. Use mprotect() to protect this block of memory,
making it read-only at all times except inside the specific accessor
functions. Now, toggle the read-only when something is changed, with
the result being that the memory is completely prevented from being
written to except when the accessor functions allow it. This way,
your characters are absolutely protected; the only time they will be
corrupted will be when an accessor function does it itself.
Extending that perhaps would be to catch the sigsegv's, check a
clean-bit guarding the char_data's, and then save all players to
backup files. No player corruption, with the added benefit of
crashing not losing player data.
This is simply not possible with macros.
There are performance issues with mprotect; however, since it is more
or less a direct call into the kernel, and since modern hardware
supports this kind of thing quite readily, there shouldn't be that
much performance loss. And I think players will greatly appreciate
the added reliability and stability.
Heck, extend it even further. When the segv occurs, use the copyover
reboot type function, autolog players back in, and be done with it.
Players see a momentary "burp" but no crash.
> Now then, I shall cease this useless chatter until you have some new facts
> to support your argument or bring up another worthy topic.
As shall I.
--
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