[vlc-devel] [PATCH 2/2] chromecast: don't close the client connection
remi at remlab.net
Wed Oct 28 15:21:19 CET 2020
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
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.
More information about the vlc-devel