+++ This bug was initially created as a clone of Bug #919127 +++ Hello, we use curl for some higher-level libraries (librepo and urlgrabber namely) and they both need to be able to setup libcurl to interrupt a hanged operation on Ctrl-C. This is currently not possible (unless Curl is compiled with a special switch) but it is essential for a good user experience in applications like Yum. There is a upstream patch proposed already: http://sourceforge.net/p/curl/bugs/1168/ --- Additional comment from Kamil Dudka on 2013-03-07 20:36:18 CET --- 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? --- Additional comment from Zdeněk Pavlas on 2013-03-08 09:09:25 CET --- 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() --- Additional comment from Ales Kozumplik on 2013-03-08 09:31:28 CET --- 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. --- Additional comment from Kamil Dudka on 2013-03-08 12:45:02 CET --- (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/ --- Additional comment from Kamil Dudka on 2013-03-11 17:30:03 CET --- proposed upstream: http://thread.gmane.org/gmane.comp.web.curl.library/38653/focus=38654 --- Additional comment from Ales Kozumplik on 2013-03-12 10:09:04 CET --- 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. --- Additional comment from Kamil Dudka on 2013-03-12 11:27:20 CET --- upstream commits: https://github.com/bagder/curl/commit/491e026c https://github.com/bagder/curl/commit/57ccdfa8 --- Additional comment from Kamil Dudka on 2013-03-12 12:18:53 CET --- fixed in curl-7.29.0-4.fc19 --- Additional comment from Fedora Update System on 2013-03-12 13:08:11 CET --- 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 --- Additional comment from Fedora Update System on 2013-03-12 13:08:25 CET --- 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
Zdenek was apparently faster with the pycurl bug, closing... *** This bug has been marked as a duplicate of bug 920589 ***