Re: curl_multi_poll check breaks previous behavior

From: Henrik Holst via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 23 Sep 2022 04:47:16 +0200

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_at_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 <daniel_at_haxx.se>
> *Sent: *Thursday, September 22, 2022 4:58 PM
> *To: *Matthew Bobowski via curl-library <curl-library_at_lists.haxx.se>
> *Cc: *Matthew Bobowski <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.html
>

-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Received on 2022-09-23