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

[Rémi Denis-Courmont]

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.

-- 
レミ・デニ-クールモン
http://www.remlab.net/