> On Thu, Dec 18, 2008 at 07:24:34PM +0100, Isidor Zeuner wrote:
> > when looking into the implementations of the timeouts with millisecond
> > resolution added in 2007, I stumbled upon the current status that there
> > are three different time sources configurable to measure accurately
> > enough so they are useful, but practically they still don't provide
> > higher resolution, because the interaction of the timing with the
> > networking code is done using sleep and poll system calls with 1 second
> > resolution.
>
> I don't follow this--both poll and select allow timeouts with millisecond
> resolution (I assume you meant select and not sleep since the latter isn't
> called in libcurl). The only timeout limited to second resolution that I can
> think of is the name resolve on systems configured to use the synchronous
> resolver.
>

I just saw I mixed the system calls up. It's not sleep that is called,
but alarm, in the synchronous resolver.

Curl_socket_ready does use poll or select depending on the system, but
inside transfer.c, it is passed only 1000ms steps from the configured
timeouts, so the transfers do effectively use a timeout resolution of
1 second, independently from select or poll being used.

> > I found that the new timout interfaces can be made useful
> > rather quickly by employing setitimer system calls and using a higher
> > resolution in the polls. Attached is a proof of concept patch which
> > integrates these changes. It may need some cleanup, especially to avoid
> > breakage using more exotic combinations of preprocessor defines, but
> > maybe it's already interesting for some people willing to experiment
> > with the timing behavior. I'd be glad to receive comments if someone
> > finds it useful or interesting.
>
> I still don't see the point of the patch on the connect call since that
> uses select/poll with millisecond resolution already, and switching to a
> signal/longjmp approach has some serious down sides. But the patch to
> use setitimer on the resolve is certainly welcome (it's TODO item #1.4).
>

In my tests, the connect call would not use the configured timeout at all,
so if dns was resolved within timeout and connect did't respond, curl
would hang for a long time. Essentially, I took the signal/longjmp logic
from the synchronous resolve part, but I agree that it is somehow messy.
Thanks for the pointer to the TODO list. I read up the thread on the signal
issue now. In fact, I first thought about an approach involving multiple
processes before implementing this, but I was rather happy that it worked
without that. But maybe on the long run, an approach using a worker process
that just dumbly does the whole communication and gets killed if it misses
timeouts would by the cleanest choice, at least on POSIX.

> I have a couple comments on that part. One is that we can't use C99-style
> named structure initializers since we aim for C89 compatibility. Another
> is that the use of the do{}while(0) construct in functions is a bit unusual
> for libcurl. Otherwise, I think it's a good idea.
>

Ok.

Best regards,

Isidor Zeuner
Received on 2008-12-19