[357] in Coldmud discussion meeting

root meeting help first first in chain previous in chain previous next last

Re: more re: text_dump()

daemon@ATHENA.MIT.EDU (Wed Jun 22 21:51:24 1994 )

From: stewarta@netcom.com (Alex Stewart)
To: deforest@netcom.com (Robert de Forest)
Date: Wed, 22 Jun 1994 18:45:46 -0700 (PDT)
Cc: coldstuff@MIT.EDU
In-Reply-To: <199406221925.MAA07777@netcom2.netcom.com> from "Robert de Forest" at Jun 22, 94 12:25:28 pm

> I thought the question was why output which was echo()ed before the call to
>  text_dump() was seen after the dump had lagged things.

This was a preliminary question into the matter, yes.

> So is the actual question how to get around this problem with a db code change
>  or how to get around this with a server change?

I think the point of the previous question was to determine which of these
questions was most feasable/appropriate as the next step in inquiries.

> I would vote for an in-db solution so as not to risk introducing a server bug.

Well, I would vote for an in-server implementation on principle (and I believe
principle should come above fears of bugs, since bugs can be fixed a lot more
easily than a flawed design can).  The principle being that it's the server's
job to get output sent with the echo() builtin out onto the network in a timely
fashion, and since text_dump is a decidedly un-timely thing, all pending IO
should be resolved before the server engages in any tasks that are known to
eat up large amounts of system time with no interruption.

Actually, it seems to me the best design would be to have network IO
event-driven anyway (I had rather assumed that this was the case already, given
that ColdMUD is better designed than MOO on most other fronts).  hopefully this
will be part of SamIAm's multithreading of the server code (anybody heard from
him at all recently, BTW?)