> On Apr 2, 2018, at 3:27 AM, Daniel Stenberg <dan...@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