[DGD] Rewriting the main loop

[Raymond Jennings]

On Fri, Nov 30, 2018 at 8:43 PM Dread Quixadhal <quixadhal at gmail.com> wrote:

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

In DGD's case, "interrupt" has a different meaning than typical.  It means
that DGD has received a SIGTERM (or equivalent) signal from the operating
system telling it to shut down.  DGD in turn handles this by firing off a
call to driverobj->interrupt().  The "interrupt" I'm speaking of has
nothing to do with sockets and as far as I know DGD doesn't use
asynchronous I/O.  I think you may be confusing it with the kind of
"interrupt" more typical to general programming outside of DGD.

I choose to treat this as a top priority event because of the impending
shutdown, and I choose to have it preempt all other action, such as user
I/O and callouts.

To be blunt, I consider some things to be more important than others, so I
rewrote the main loop so that the higher priority stuff gets the right of
way, so to speak.


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

LPC tasks are not frozen.  They are executed in response to events (new
connection, new input on an existing connection, a callout going off, or
the operating system signalling a shutdown).  You can't "pause" in the
middle of a task/execution round.

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

Something tells me you completely misunderstood what DGD is actually doing.

What I'm trying to do is have some events take priority over others.
Namely, that I want OS shutdown signals processed immediately, otherwise I
want user input/new connections to be taken care of first before callouts
are processed, and I want DGD to save its background housekeeping for when
it isn't otherwise busy handling the aforementioned events.  And I have it
do its background work serially with as small of a step as possible to keep
it responsive.  Like for example, if something happens while DGD is busy
swapping unused objects to disk, I want it to only swap one object at a
time so that if someone sends input or a callout goes off, DGD doesn't get
caught with its proverbial pants down longer than necessary.

Did either of us misunderstand what I was talking about?

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
>
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd