Re: Embedded platforms (without FPU's), etc.
Date: Mon, 2 Apr 2018 11:27:58 +0200 (CEST)
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) +
For what option(s) would this be used?
> 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
> 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.
> 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.
-- / daniel.haxx.se
Received on 2018-04-02