> 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.

I was looking at <include/curl/system.h> and it’s a little hairy. Can we just do something simple/stupid, like include <stdint.h> and if uint64_t is included then we support these timestamps, and if not, then we don’t?

>
> 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?

  /* Fill in new entries below here! */
  CURLINFO_TOTAL_TIME_T = CURLINFO_USECS + 50,
  CURLINFO_NAMELOOKUP_TIME_T = CURLINFO_USECS + 51,
  CURLINFO_CONNECT_TIME_T = CURLINFO_USECS + 52,
  CURLINFO_PRETRANSFER_TIME_T = CURLINFO_USECS + 53,
  CURLINFO_STARTTRANSFER_TIME_T = CURLINFO_USECS + 54,
  CURLINFO_REDIRECT_TIME_T = CURLINFO_USECS + 55,
  CURLINFO_APPCONNECT_TIME_T = CURLINFO_USECS_T + 56,

>
>> 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.

I couldn’t figure out if that’s guaranteed to be 64-bits in all cases. Like here:

#else
/* generic "safe guess" on old 32 bit style */
# define CURL_TYPEOF_CURL_OFF_T long
# define CURL_FORMAT_CURL_OFF_T "ld"
# define CURL_FORMAT_CURL_OFF_TU "lu"
# define CURL_SUFFIX_CURL_OFF_T L
# define CURL_SUFFIX_CURL_OFF_TU UL
# define CURL_TYPEOF_CURL_SOCKLEN_T int
#endif

I haven’t touched a System 370 since college, for instance… or a Watcom or Borland compiler, for that matter.

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

Could the debug function be overloaded?

-Philip

>
>> 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.
>

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