> On Nov 19, 2018, at 19:14, 宋辰伟 <616955...@qq.com> wrote:
>
> Currently QUIC event doesn’t use the epoll in ET_NET, SO it is a really a
> problem.
Ah. Yes, part of our planning session included moving all this to ET_NET. That
is part of using connect+bind on the QUIC sessions.
Cheers,
— Leif
>
>
>> 在 2018年11月20日，上午10:10，Leif Hedstrom <zw...@apache.org> 写道：
>>
>>
>>> On Nov 19, 2018, at 18:47, 宋辰伟 <616955...@qq.com> wrote:
>>>
>>> Hi
>>>
>>> Actually there is some blocking operation during ats like epoll. We are
>>> blocking at epoll for several times and until the net event arrived. So if
>>> any other event (which is not net event) schedule it will be pended until
>>> epoll’s timeout fired unless you use the signal to terminate blocking.
>>
>> Yeh sure, but in theory at least if there are active connections epoll would
>> almost always have events :).
>>
>> But yes, things not on the epoll event loop could get stuck on low activity
>> boxes. Speaking of, there might still be improvements to do here with
>> timerfd and eventfd. We did soMe work there a few years ago.
>>
>> Cheers,
>>
>> — Leif
>>>
>>> Scw00
>>>
>>>> 在 2018年11月20日，上午9:21，Walt Karas <wka...@oath.com.INVALID> 写道：
>>>>
>>>> What strategy or strategies do we use in ATS to make sure that we
>>>> don't do blocking I/O that blocks a thread with queued event handlers
>>>> (not dependent on the I/O operation)?
>>>>> On Mon, Nov 19, 2018 at 7:13 PM Masakazu Kitajo <m4s...@gmail.com> wrote:
>>>>>
>>>>> I have no idea where the delay comes from. I posted its detail on the PR (
>>>>> https://github.com/apache/trafficserver/issues/3552#issuecomment-440099449).
>>>>>
>>>>> Thanks,
>>>>> Masakazu
>>>>>
>>>>>> On Mon, Nov 19, 2018 at 5:30 PM 宋辰伟 <616955...@qq.com> wrote:
>>>>>>
>>>>>> Hi maskit and koshiba
>>>>>>
>>>>>> What does 30ms delay means ? How to reproduce it ?
>>>>>>
>>>>>> SCW00
>>>>>>
>>>>>>> 在 2018年11月19日，上午9:12，Masakazu Kitajo <mas...@apache.org> 写道：
>>>>>>>
>>>>>>> seem
>>>>>>
>>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
