> On Apr 2, 2018, at 3:27 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:
>
> On Sat, 31 Mar 2018, Philip Prindeville wrote:
>
>> Couple of questions. One is a broader question about tweaking the API so that it uses fewer “doubles” for get curl_easy_getinfo() call, in particular using fixed point since you might be running on a platform such as an embedded router with a MIPS-32 or ARMv6 CPU which doesn’t have floating-point… but is reasonably capable of 64-bit operations (shifting, adding, subtracting, etc).
>
> We've slowly been moving in that direction over time. As Harold mentioned, that easily conflicts with other limitation: not having 64 bit support.
>
> IMO, the most important thing would be to not have floating point operations in "the critical path" since most systems still have soft float support.
>
>> So we might want to express times as uint64_t’s as (tv.tv_sec * 1000000) + tv.usec.
>
> For what option(s) would this be used?

Anything timestamp related, so CURLINFO_TOTAL_TIME, CURLINFO_CONNECTTIME, CURLINFO_APPCONNECT_TIME, CURLINFO_PRETRANSFER_TIME, CURLINFO_STARTTRANSFER_TIME, et al.

>
>> Not sure why some values like bytes downloaded need to be “doubles”. Again, uint64_t would be ideal here.
>
> I think we offer most of those values as 'curl_off_t' numbers if you use the modern versions.

Some of the platforms I have to use have regrettably old toolchains and run-times.

The link https://curl.haxx.se/libcurl/c/CURLINFO_SIZE_DOWNLOAD.html says:

CURLcode curl_easy_getinfo(CURL *handle, CURLINFO_SIZE_DOWNLOAD, double *dlp);

but maybe that’s not current.

>
>> I can come up with a set of patches that support uint64_t’s in more places.
>
> Sure. If those changes actually make a difference in a real world application then I think those can be good improvements.

Well, my universe is perhaps different from most: it’s about trying to breathe new life and functionality into $40 routers that are in some cases 10 years old and haven’t been updated in almost as long…

This is a set of constraints that most people are (happily) not burdened with.

>
>> Lastly—as you might guess, I’m doing development for platforms which don’t have FPU’s—and I need to retrieve the delay from calling curl_easy_perform() and the socket completing a connect().
>
> And you can explain some of that time on floating point operations? Well then we should certainly make sure those don't happen.

I don’t know the overhead from using soft FP libraries on all of the platforms, but the point is that there are means that are both faster and don’t sacrifice an precision. It also means not having to link the sometimes largish libraries into the apps (for platforms which don’t support DSO’s or support them poorly, due to broken library versioning, inconsistent ABI enforcement, etc).

>
>> Is there some easy way to use a callback that gets called immediately after the connect() completes?
>
> No, we have no such dedicated callback.

Ah. Because then could store whatever representation one wanted… well, no matter.

>
>> For instance, the first time XFERFUNCTION gets called and then immediately unset the hook (inside the handler)?
>
> XFERFUNCTION may be called numerous times before the connect() completes if you have slow name lookup or otherwise slow network.
>
> libcurl is purposedly focused on transfers and doesn't really try to expose such specific events or states as "connect completed" within each transfer. libcurl also supports transfers without connects.
>

For… TFTP and such?

-Philip

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