[vlc-devel] [PATCH 2/2] chromecast: don't close the client connection

[Thomas Guillem]

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

> 
> -- 
> レミ・デニ-クールモン
> http://www.remlab.net/
> 
> 
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel