Bug 919127

Thanks for the patch and the upstream proposal.  Could you please provide a pycurl-based test code that can be used to verify that libcurl behaves as expected?

Run this, then hit ctrl-c.  When curl and pycurl are patched, perform() should immediately raise pycurl.error: (28, 'connect() timed out!').  Otherwise, ctrl-c is ignored, and you have to wait for a minute or sigkill this.

import pycurl
if hasattr(pycurl, 'GLOBAL_ACK_EINTR'):
    pycurl.global_init(pycurl.GLOBAL_ACK_EINTR)
c = pycurl.Curl()
c.setopt(pycurl.CONNECTTIMEOUT, 60)
c.setopt(pycurl.URL, 'http://10.10.10.0')
c.perform()

Also: we are not explicitly focusing on the pycurl case but mostly on the C curl library where the root cause of this problem is. for instance librepo does not use the curl python bindings at all.

(In reply to comment #3)
> Also: we are not explicitly focusing on the pycurl case but mostly on the C
> curl library where the root cause of this problem is. for instance librepo
> does not use the curl python bindings at all.

That sounds wrong to me.  If you write a generic enough library, you do not know in advance how the user of your library will use signals.  Hence, initializing libcurl this way in a library will sooner or later cause a bad surprise elsewhere.  I strongly suggest to use the multi interface instead, which allows you much more than the proposed patch.

We were discussing this with Zdenek before in the context of pycurl and yum as an application.  The only reason for not using the multi interface in yum was the performance penalty caused by implementing the select() loop in python.  However, this reason does not exist in a C library.  You can see that the easy interface is now implemented as a wrapper around the multi interface even in libcurl itself:

http://daniel.haxx.se/blog/2013/01/17/internally-were-all-multi-now/

proposed upstream:

http://thread.gmane.org/gmane.comp.web.curl.library/38653/focus=38654

Thanks for the proposed patches Kamil.

(In reply to comment #4)
> That sounds wrong to me.  If you write a generic enough library, you do not
> know in advance how the user of your library will use signals.  Hence,
> initializing libcurl this way in a library will sooner or later cause a bad
> surprise elsewhere.  I strongly suggest to use the multi interface instead,
> which allows you much more than the proposed patch.

Adding tmlcoch. Tomas, this opinion of Kamil is probably something you should be aware of, even if you decide against going for this approach.

upstream commits:

https://github.com/bagder/curl/commit/491e026c
https://github.com/bagder/curl/commit/57ccdfa8

fixed in curl-7.29.0-4.fc19

curl-7.27.0-7.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/curl-7.27.0-7.fc18

curl-7.24.0-6.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/curl-7.24.0-6.fc17

Package curl-7.24.0-6.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing curl-7.24.0-6.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-3757/curl-7.24.0-6.fc17
then log in and leave karma (feedback).

curl-7.27.0-7.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

curl-7.24.0-6.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.