[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