Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.1.8 2020-08-04T10:34:38Z 2020-08-04T10:34:38Z Julian Andres Klode jak@debian.org 2020-08-04T10:34:38Z urn:sha1:7d222636954ec95382149e31b314e9828ba05a2e Pu/http fixes 2 See merge request apt-team/apt!125 2020-08-04T10:12:30Z Julian Andres Klode jak@debian.org 2020-08-04T10:12:30Z urn:sha1:11530bab64efd4b4fc46de7833533cea9c69f521 Remove master/slave terminology See merge request apt-team/apt!124 2020-08-04T10:12:11Z Julian Andres Klode julian.klode@canonical.com 2020-07-14T14:19:08Z urn:sha1:9cb5a81168307e15f209173ad9286835bff2df65 2020-08-04T09:46:39Z Julian Andres Klode julian.klode@canonical.com 2020-08-04T09:37:45Z urn:sha1:27d36318b98f3a070fb24557ce691718ef4eec34 We only add the file to the select() call if we have data to write to it prior to the select() call. This is problematic: Assuming we enter Go() with no data to write to the file, but we read some from the server as well as an EOF, we end up not writing it to the file because we did not add the file to the select. We can't always add the file to the select(), because it's basically always ready and we don't want to wake up if we don't have anything to read or write. So for a solution, let's just always write data to the file if there's data to write to it. If some gets leftover, or if some was already present when we started Go(), it will still be added to the select() call and unblock it. Closes: #959518 2020-07-24T14:30:43Z Julian Andres Klode julian.klode@canonical.com 2020-06-29T12:03:21Z urn:sha1:08f05aa8beb58fa32485e2087eb21a9f3cb267bb Instead of reading the data early, disable the timeout for the select() call and read the data later. Also, change Read() to call only once to drain the buffer in such instances. We could optimize this to call read() multiple times if there is also pending stuff on the socket, but that it slightly more complex and should not provide any benefits. 2020-07-24T14:30:43Z Julian Andres Klode julian.klode@canonical.com 2020-06-29T10:31:55Z urn:sha1:c2cb8abbf5d8a49b25071ffffca93a083fe725fc The error handling in Die() that's supposed to add useful error messages is not super useful here. 2020-07-24T14:30:43Z Julian Andres Klode julian.klode@canonical.com 2020-06-29T10:23:02Z urn:sha1:9742032dcdc0e72c117ae0c589fbb59452d6d33c This avoids a case where we read data, then write to the server and only then realize the connection was closed. It is somewhat slower, though. 2020-07-24T14:30:43Z Julian Andres Klode julian.klode@canonical.com 2020-06-29T09:48:28Z urn:sha1:24d308455a5f8751f57219f211a5672af340099e By changing the buffer implementation to return true if it read or wrote something, even on EOF, we should not have a need to flush the buffer in Die() anymore - we should only be calling Die() if the buffer is empty now. 2020-07-24T14:30:43Z Julian Andres Klode julian.klode@canonical.com 2020-06-29T09:45:45Z urn:sha1:cb743d117bcc666dab4c5948b1227ed2edbd0578 This should avoid the need to Flush the buffer in Die(), because if we read anything, we are returning true, and not entering Die() at that point. Also Write() does not have a concept of EOF, so get rid of code handling that there. Was that copied from Read()? 2020-07-24T14:30:43Z Julian Andres Klode julian.klode@canonical.com 2020-06-29T09:37:29Z urn:sha1:1ee3b64be054a8deb6a598d93047637448e1928e Die() needs its own Copy() of Flush() because it needs to return success or failure based on some states, but those are not precisely the same as Flush(), as Flush() will always return false at the end, for example, but we want to fall through to our error handling.