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