[DGD] Rewriting the main loop

[bart at wotf.org]

Or move the risk? (note.. swapout)

Strict priority is a bad idea (tm) when it prevents lower priority tasks from
ever getting to run. If you insist on strict priority, you *MUST* implement a
mechanism to temporary raise the priority of things that would never get to
run otherwise.

That is something every multitasking OS designer either already knows or has
to find out the hard way, you can pick one of both catagories.

Working around the issue with resource management is not a solution, not to
mention, the resource management solution you propose has been discussed quite
a bit, it does not work with hydra for easy to understand reasons. To manage
call_outs that way means you need a central location for keeping track of
that, which does not play nice with Hydra (this has a history in the kernel
lib that you maintain, provided you didn't break the commit history again, you
should be able to find the appropriate commits about this I suppose, if not,
there is stuff in the mailinglist about this)

Bart.

On Fri, 30 Nov 2018 19:48:49 -0800, Raymond Jennings wrote
> Ok, so for the callout table, would a klib style resource quota mitigate
> the risk?
> 
> And was there anything else I might have missed?
> 
> On Thu, Nov 29, 2018 at 2:03 PM Raymond Jennings 
> <shentino at gmail.com> wrote:
> 
> > On Thu, Nov 29, 2018 at 10:06 AM Felix A. Croes <felix at dworkin.nl> wrote:
> >
> >> Raymond Jennings <shentino at gmail.com> wrote:
> >>
> >> > On Thu, Nov 29, 2018 at 3:23 AM Felix A. Croes <felix at dworkin.nl>
> >> wrote:
> >> >[...]
> >> > I've decided to forgo the benefits of Hydra until such time, if any, as
> >> > this feature merges with DGD
> >>
> >> Well then, since keeping DGD and Hydra compatible at the mudlib level
> >> is important to me but not to you, and since you've kept bringing up
> >> this issue for years, I suggest that you grant the benefit of "strict
> >> priority" to your own fork of DGD.
> >>
> >> >[..]
> >> > > That is not going to work when user input has higher priority than
> >> > > callouts.  It can prevent progress even when starvation of callouts
> >> > > by user input is not total.
> >> > >
> >> >
> >> > This part is new.
> >> >
> >> > How is it even possible?  Unless my mud is getting flooded with an I/O
> >> > storm (possibly from a denial of service attack), won't all the callouts
> >> > get fired eventually?
> >>
> >> All that has to happen to cause the callout table to fill up is for
> >> callouts to be added, from I/O-started tasks, faster than they are
> >> being executed.
> >>
> >
> > So effectively it would be a denial of service attack against the callout
> > table?
> >
> > Regards,
> >> Felix Croes
> >> ____________________________________________
> >> https://mail.dworkin.nl/mailman/listinfo/dgd
> >
> >
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd


--
https://www.bartsplace.net/
https://wotf.org/
https://www.flickr.com/photos/mrobjective/