[DGD] Rewriting the main loop

[Dread Quixadhal]

I guess I’m confused as to the purpose of this change.

Interrupts, for a MUD driver, would be data arriving at a socket, an asynchronous I/O thread completing, or a signal, right?  Obviously you want this to be handled swiftly, but if it’s delayed a bit while other LPC code is processed, it won’t make a difference to the LPC code, will it?

I presume by I/O, you mean a synchronous read/write to some handle or resource.  When coding in LPC, you presumably either know this won’t take long and do it directly, or you know it might take a while and use an async call with a callback.  So, I’d expect for those synchronous calls, either they’ll complete before the next step in the loop, or will timeout and that LPC task will have to remain frozen until they complete in the next loop.  One assumes if the LPC coder cares, they’ll use a callback to avoid the hang.

What’s the goal of doing this?  Are you trying to make a real-time kernel where LPC tasks can respond to things with fixed timing?  If so, you’ll need to allow LPC tasks to have priorities amongst themselves, since not everything needs (or can be) real-time responsive.

Sent from Mail for Windows 10

From: Raymond Jennings
Sent: Friday, November 30, 2018 7:49 PM
To: All about Dworkin's Game Driver
Subject: Re: [DGD] Rewriting the main loop

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