[DGD] Rewriting the main loop

Raymond Jennings shentino at gmail.com
Mon Dec 3 00:41:04 CET 2018


On Sun, Dec 2, 2018 at 3:32 PM Raymond Jennings <shentino at gmail.com> wrote:

> On Sun, Dec 2, 2018 at 3:14 AM Felix A. Croes <felix at dworkin.nl> wrote:
>
>> Raymond Jennings <shentino at gmail.com> wrote:
>>
>> > On Sat, Dec 1, 2018 at 5:37 PM Schmidt, Stephen <schmidsj at union.edu>
>> wrote:
>> >
>> > > On Sat, Dec 1, 2018 at 8:28 PM Raymond Jennings <shentino at gmail.com>
>> > > wrote:
>> > >
>> > > > As for the reason:
>> > > >
>> > > > It is my personal opinion that DGD should be as responsive as
>> possible,
>>
>> I suppose that this is what you imagine you are having a difference
>> of opinion about?  Actually, this is a refusal to see that your basic
>> assumptions are wrong, and that your proffered solution would be a
>> disaster even if they weren't.
>>
>> >[...]
>> > > I'm not sure I understand the distinction here. Won't it often,
>> perhaps
>> > > generally, be the case that the callouts are part of the human
>> interaction?
>> >
>> > It depends on what the interaction is.
>>
>> Don't hold forth as if you are an expert on things DGD.  Stephen
>> understands this better than you do, and he is showing you one of
>> the errors in your thinking.
>>
>> Most perplexingly, this has mostly been a replay of an earlier discussion
>> that we've had off-list 6 years ago.  In the intervening years you have
>> learned nothing;
>
>
> I must admit that my memory isn't that great.
>
>
>> when the same flaws are pointed out to you, you dismiss
>> that as a difference of opinion.  When I went into further detail, you
>> even had the gall to remark, "This part is new", before discarding that,
>> too, with all the rest.
>>
>
> I apologize if I was appearing to dismiss the idea.  When you mentioned
> callout starvation here:
>
> > 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.
>
> It sounded like a problem that already existed even in vanilla DGD.  So my
> "discarding" if any wasn't so much "meh, who cares?" as much as "this is
> already an issue".  I'm also still failing to grasp why a resource quota
> wouldn't stop this from happening.  As it is I already have code in my
> second auto object that forbids starting a callout from non System code if
> the number of free callouts globally (status(ST_COTABSIZE) -
> (status(ST_NCOSHORT) + status(ST_NCOLONG))) is below a small percentage of
> the table size.  Why won't that work to prevent a lowly user object from
> consuming all the callouts to the point of sabotaging my System code?
>

My guess is that your point is that yielding to user I/O can let callouts
keep piling up to the point where the callout table chokes, whereas leaving
it as is with Vanilla DGD causes user I/O to properly "wait its turn" as it
were and yield to callouts that were already due to give them a chance to
process.


> Either there's been a misunderstanding or I'm still missing something.
>
>
>> I have honestly reached the end of my patience with you.  I will not
>> be participating in any further discussions with you on the subject.
>>
>
> As you wish.  If clearing up this misunderstanding doesn't help matters
> then I apologize.
>
>
>> Regards,
>> Felix Croes
>> ____________________________________________
>> https://mail.dworkin.nl/mailman/listinfo/dgd
>
>



More information about the DGD mailing list