I don't think Daniel is against using -1 as the value for initine timeout, I think that he simply means that he is willing to accept a patch that both does that AND makes it a documented feature.
/HH Den fre 23 sep. 2022 kl 02:34 skrev Matthew Bobowski via curl-library < curl-library@lists.haxx.se>: > Daniel, > > > > Thank you for your prompt response and your support of libcurl. > > > > Regarding this issue: While better documentation would have been helpful > to avoid this occurrence, the ask is to *revert to previous behavior*. > The reasons include: > > 1. The current behavior breaks existing implementation and in itself > returns an undocumented return code for libcurl v7.68.0. Error 10 is > defined as CURLM_LAST in libcurl 7.68, which is merely a placeholder > for future expansion. So, implementations developed against 7.68 have no > idea what went wrong when they receive an unexpected and unknown error > code. > 2. Nearly all Windows and POSIX implementations and APIs use -1 or > 0xFFFFFFFF for this behavior. In fact INFINITE is defined as such in > WinBase.h. Additionally, libcurl takes advantage of this behavior > internally by resetting negative timeouts to -1 to explicitly disable the > timeout for this very reason for both implementations with Linux poll() > and Winsock WSAWaitForMultipleEvents(). > > > > The end result is existing customers in the field cannot reliably update > to the latest version of libcurl since the behavior has changed and an > error (with new code) occurs when none did previously. The previous > behavior was quite well tested and reliable – albeit not explicitly > documented, it is inferred from myself and others with many years of > programming experience with underlying OS APIs and is the expected behavior > to wait (for at least the maximum time). This change would seem to hinder > the adoption of libcurl as behavior is broken with forward compatibility in > the integrators product. > > > > What would it take to revert this behavior? > > > > > > Thanks and with much appreciation, > > -Matt > > > > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for > Windows > > > > *From: *Daniel Stenberg <dan...@haxx.se> > *Sent: *Thursday, September 22, 2022 4:58 PM > *To: *Matthew Bobowski via curl-library <curl-library@lists.haxx.se> > *Cc: *Matthew Bobowski <mjb8...@hotmail.com> > *Subject: *Re: curl_multi_poll check breaks previous behavior > > > > On Thu, 22 Sep 2022, Matthew Bobowski via curl-library wrote: > > > I am curious as to why this change was made which breaks expected > behavior. > > The expected behavior from any libcurl function is what is documented - if > it > isn't documented, the behavior is not reliable. > > The handling of negative arguments was incidental and by chance it worked > like > you described. There was no *deliberate* handling of negative values. As > such, > users could either take advantage of the undocumented behavior or they > could > be surprised and something would go wrong. > > Now, I suspect you actually did not only want to ask *why* we changed that > but > rather if we can add *documented* support for infinite timeouts? > > I think we could. > > -- > > / daniel.haxx.se > | Commercial curl support up to 24x7 is available! > | Private help, bug fixes, support, ports, new features > | https://curl.se/support.html > > > -- > Unsubscribe: https://lists.haxx.se/listinfo/curl-library > Etiquette: https://curl.se/mail/etiquette.html >
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
