> 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

Reply via email to