[vlc-devel] [PATCH 2/2] chromecast: don't close the client connection
Thomas Guillem
thomas at gllm.fr
Wed Oct 28 15:45:21 CET 2020
On Wed, Oct 28, 2020, at 15:38, Thomas Guillem wrote:
>
>
> On Wed, Oct 28, 2020, at 15:21, Rémi Denis-Courmont wrote:
> > Le keskiviikkona 28. lokakuuta 2020, 14.35.33 EET Thomas Guillem a écrit :
> > > By default, delay is -1, that mean an infinite timeout from poll. Once the
> > > chromecast is ready to read, poll returns (in the current situation with
> > > delay = -1 it can return after 20sec for example),
> >
> > I think you are confused about how poll() works. The first wait for POLLOUT
> > event will *always* return immediately, because the send buffer is
> > intrinsically empty and has room to write in TCP buffers.
> >
> > So this cannot cause a 20 seconds time-out.
> >
> > > then httpd_ClientSend() succeed and then, 2 choices:
> > > - activitiy_date is updated before checking the timeout
> > > (before your patches): OK, we didn't kill a client that timeouted
> > > for more than 10secs.
> >
> > > I think it's a bug
> > > - activitiy_date is updated after checking the timeout (after your patches);
> >
> > No. At that point, we have spent some fractions of seconds in poll() and in
> > non-blocking I/O and URL callbacks. The time-out is still 8-9 seconds in the
> > future, and we update the activity date as before, then go back to poll(), as
> > before.
> >
> > There are only two ways that this fails:
> >
> > 1) The process was somehow stopped (e.g. by debugger). This is not a new
> > problem, not a normal circumstance, and not really avoidable.
> >
> > 2) An URL callback, a mutex or something else got stuck in what is supposed to
> > be non-blocking I/O. This breaks the whole HTTPd instance thread including all
> > other clients (notably the HTTP interface). Whatever would cause this needs to
> > be fixed. The timeout is just a canary safety in this case (and because it is a
> > safety measure, it needs to be kept).
> >
> > > My patch set is only touching the chromecast.
> >
> > No it's not. As said, there can be concurrent clients of the HTTP instance,
> > most notably/likely the HTTP interface.
>
> Chromecast created its own http server a non default port. I don't see
> the point with the HTTP interface
fixing comment typo:
Chromecast creates its own http server on a non default port. I don't see the interaction with the HTTP interface.
>
> >
> > --
> > レミ・デニ-クールモン
> > http://www.remlab.net/
> >
> >
> >
> > _______________________________________________
> > vlc-devel mailing list
> > To unsubscribe or modify your subscription options:
> > https://mailman.videolan.org/listinfo/vlc-devel
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
More information about the vlc-devel
mailing list