> -----Original Message-----
> From: curl-library [mailto:curl-library-bounces_at_cool.haxx.se] On Behalf Of
> Daniel Stenberg
> Sent: Tuesday, March 20, 2018 5:50 PM
> To: libcurl development <curl-library_at_cool.haxx.se>
> Subject: RE: Wait for a response using curl_multi_wait
>
> On Tue, 20 Mar 2018, Cunningham, Joel wrote:
>
> > curl_multi_wait() has been particularly hard to integrate with in a
> > manner which doesn’t unnecessarily sleep and end up in a tight loop.
> > What I’ve found is the main issue is a lack of information about if
> > any waiting was actually done.
>
> Yeah.
>
> When we added curl_multi_wait() to offer a simpler API, we clearly missed
> out on exactly that detail and it unfortunately makes the function hard to use
> in an effective way. And not that easy and convenient as I wanted it to be
> and which was the original plan.
>
> Let's say we would introduce an improved version of this function. How
> would you propose its API would work to reduce the current annoyance as
> much as possible?

My thoughts are either:

1) Make the new API behave just poll/select, i.e. it can be used as a blocking construct even when there are no input FDs.

Given a background in network programming, my initial assumption when first encountering curl_multi_wait() was that it would behave in this way since it took FDs and had "wait" in the name. Only after reading the docs did I realize it was much more complicated than that.

I found a previous discussion about this on the mailing list [1] but it's not clear why the 'not waiting' behavior was preferred

2) Have the API behavior (not waiting in some cases) be the same, but return some indication of whether any waiting was done. Maybe this is through an additional parameter?

Optionally waiting seems to be the motivation behind the current API behavior [1], but I'm not sure I understand the use case of passing a timeout into curl_multi_wait() but then not wanting to actually wait that entire time. I would figure the user would use a 0 timeout in this case.

This second option would probably not help clarify the API for new users and they may still integrate in a non-performant manner, but it would be helpful for those already familiar with this issue.

>
> curl_multi_wait_done_again() (yes, the name can also be discussed)

[1] https://curl.haxx.se/mail/lib-2012-10/0078.html

Joel

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-03-21