On Sun, 19 Dec 2004, Martijn Koster wrote:

(this is a libcurl issue, I CC my reply to the libcurl list and I suggest you
take follow-ups there)

> I've made a documented testcase for the problem on
> http://www.greenhills.co.uk/mak/gentoo/curl-eintr-bug.c which I hope will
> enable you to look into this issue further.

I'm not 100% sure we should deal with "aborted by signal" by simply
recovering. Why do we get the signal in the first place? AFAIK, libcurl itself
never causes such a signal to arrive and thus an externel source has sent it.

The question is then: if an external source sends a signal to this process and
it is intercepted while libcurl is running, what is the correct and expected
behaviour?

If we assume that we should re-issue the function as your patch does, I have
two suggestions:

1. Make a patch against CVS / a daily snapshot since the select() stuff is
    modified a lot since 7.12.2. We now also use _either_ poll or select so the
    check would need to be at two places. And properly #ifdef'ed, since not
    all platforms have EINTR defined.

2. The 'timeout' value needs to be updated between the retries, as otherwise
    you can effectively make the loop go on forever by simply sending the
    process a signal with the proper interval.

Note that this change is not gonna make it to the 7.12.3 release, since I'm
creating that as we speak...

-- 
      Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
       Dedicated custom curl help for hire: http://haxx.se/curl.html