Re: [GIT PULL] ncns update (chunked request body support)

[Alviro Iskandar Setiawan <alviro.iskandar@gnuweeb.org>]

On Fri, Aug 26, 2022 at 8:34 AM Alviro Iskandar Setiawan wrote:
> On Fri, Aug 26, 2022 at 1:36 AM Ammar Faizi wrote:
> > On 8/25/22 4:57 PM, Alviro Iskandar Setiawan wrote:
> > > pulled into my next branch for testing only, tq
> >
> > I am not sure what is going on here, but it always fails when
> > the written bytes is more than 16K bytes. The current WIP commit
> > is here:
> >
> > https://gitlab.torproject.org/ammarfaizi2/ncns/-/commit/20627519f6e882ab7d2309f6a6b6e451fb19edc4
> >
> > Can you spot a mistake in this version?
> >
> > I have been debugging this for more than 5 hours and haven't
> > been able to figure out what is going wrong. I was going to
> > say that it's a Chromium bug. But thinking of the Chromium
> > stability so far, I doubt to claim so.
>
> you're tired, get some rest plz, tq for your hard work
>
> > Please review!
>
> found it, the problem is not in that commit, but the previous one
>
> https://gitlab.torproject.org/ammarfaizi2/ncns/-/commit/d113a1611f2eca1f45fd8dd0fe3a02aa92abeb6e#63c8f17eb62643be824f57c1bed41bbf7c80ed5e_50_127
>
> if you split the buffer in the middle of the queue, then you put the
> rest of the splitted buffer into the tail, then it may get skipped
> because the EOF mark can be queued earlier. Even if it doesn't hit EOF
> it's still wrong because the FIFO order is violated when the condition
> (c.len_ <= dst_len_) evaluates to true

better way you shouldn't pop the queue if you're running out of
destination buffer, you can wait for the next ReadInternal() call and
copy the rest uncopied bytes later time, only the deferring is a bit
tricky

tq

-- Viro