Let me rephrase that, the new API behaves the same as the TSContSchedule
with 0 timeout after PR#6103, which will handle events as soon as possible.
While this is good for delays, it also causes the situation scw00 brought
up (dead loop). And since there is no good way of differentiating this
behavior with the original one where the event is put into the
EventQueueExternal, and waiting for the next eventloop (with possible 60ms
delay if on the same thread). So I want to change the
current TSContSchedule code to make sure that we are not suffering from a
dead loop, and also create a new API such that the new execute ASAP is
retained.

On Tue, Nov 19, 2019 at 6:06 PM Leif Hedstrom <zw...@apache.org> wrote:

>
>
> > On Nov 20, 2019, at 05:52, Fei Deng <duke8...@apache.org> wrote:
> >
> > Forgot to mention that this change would restore the old behavior of
> > TSContSchedule minus the delay and dead loop.
> >
> >> On Tue, Nov 19, 2019 at 2:39 PM Fei Deng <duke8...@apache.org> wrote:
> >>
> >> While PR#6103 (https://github.com/apache/trafficserver/pull/6103)
> solves
> >> the problem of having the 60ms delay (caused by waiting in sleep), it
> also
> >> creates an issue where the event loop ends up in a "dead loop" if the
> >> scheduled event schedules itself with 0 timeout (see test code by
> scw00).
> >> Here's what I have in mind that will fix the problem.
> >>
> >>
> >>   1. New API "TSContDispatch", which will be basically the current
> >>   "TSContSchedule" calls with 0 timeouts.
>
>
> Dumb question, why do we need a new API, if it behaves the same as a call
> to TSContSchedule with a timeout of 0?
>
> I’m getting pretty concerned about these changes, as I think we all agree,
> this is critical code, and it’s (as we are seeing) easy to break things in
> bad ways.
>
> — Leif
>
> >>   2. When scheduling events/continuations using "TSContSchedule" API
> with
> >>   0 timeouts, set flag to identify the event to be processed on the next
> >>   event loop.
> >>   3. New "LocalQueue" class to handle events that are supposed to be
> >>   processed in the next event loop.
> >>
> >> Here's the branch I'm working on right now, it shows an easy concept of
> the
> >> "LocalQueue".
> >> https://github.com/duke8253/trafficserver/tree/master-event_dispatch
> >>
>
>

Reply via email to