[DGD] Rewriting the main loop

Raymond Jennings shentino at gmail.com
Sat Dec 1 04:48:49 CET 2018


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
>
>



More information about the DGD mailing list