Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
RE: curl_multi_poll check breaks previous behavior
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Matthew Bobowski via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 23 Sep 2022 00:34:09 +0000
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<mailto:daniel_at_haxx.se>
Sent: Thursday, September 22, 2022 4:58 PM
To: Matthew Bobowski via curl-library<mailto:curl-library_at_lists.haxx.se>
Cc: Matthew Bobowski<mailto:mjb8034_at_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.
Date: Fri, 23 Sep 2022 00:34:09 +0000
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<mailto:daniel_at_haxx.se>
Sent: Thursday, September 22, 2022 4:58 PM
To: Matthew Bobowski via curl-library<mailto:curl-library_at_lists.haxx.se>
Cc: Matthew Bobowski<mailto:mjb8034_at_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.htmlReceived on 2022-09-23