[DGD] priority of user/network i/o vs callouts

[Raymond Jennings]

My notion is actually that users just hate being kept waiting, especially
for actions that consume zero game/IC time :P

I find it ironic though that you suggest resource limits after removing
them as a resource from the klib (I tease, of course).

Mostly I agree with your reasoning though.  Even if my priorities are
different.  Either way I do appreciate the explanation, until now the
status quo didn't even make any sense.


On Sun, Feb 16, 2014 at 7:59 AM, Felix A. Croes <felix at dworkin.nl> wrote:

> Raymond Jennings <shentino at gmail.com> wrote:
>
> > I remember one time you said you'd refuse any patches that rearranged
> > things so that callouts were pushed behind user i/o or something.
> >
> > Did I get that right, and if so...why is dgd's design based on this
> > relative priority?
> >
> > My personal choice would be to have interrupts at top priority, then
> > handling i/o, then callouts, and finally housekeeping.
>
> Interrupts in DGD are triggered by kill signals.  Signals are a
> rudimentary form of inter-process communication, and as such they are
> a very poor choice for the highest priority.
>
> Callouts must have higher priority than user input because there will
> be many callouts for each user command; this is not true for the classic
> mudlibs, but it is true for modern ones (e.g. Discworld) and for non-mud
> uses.  Callouts are already kept in check by the fact that they are
> run in batches, and a callout started from one batch will not execute
> until the next batch at the earliest, with user input handled in between
> those batches.
>
> The idea that callouts should have lower priority than user input is
> prompted by the notion that admins can login and stop callout explosions.
> That doesn't really work anyway, and callout explosions are best prevented
> in a different way, for instance by imposing resource limits.
>
> Regards,
> Felix Croes
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>