Bug 920593 - provide a CURL_GLOBAL_ACK_EINTR flag to curl_global_init()
Summary: provide a CURL_GLOBAL_ACK_EINTR flag to curl_global_init()
Keywords:
Status: CLOSED DUPLICATE of bug 920589
Alias: None
Product: Fedora
Classification: Fedora
Component: python-pycurl
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kamil Dudka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 919127
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-03-12 12:10 UTC by Kamil Dudka
Modified: 2013-03-12 15:12 UTC (History)
6 users (show)

Fixed In Version:
Clone Of: 919127
Environment:
Last Closed: 2013-03-12 15:12:06 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Kamil Dudka 2013-03-12 12:10:28 UTC
+++ 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

Comment 1 Kamil Dudka 2013-03-12 15:12:06 UTC
Zdenek was apparently faster with the pycurl bug, closing...

*** This bug has been marked as a duplicate of bug 920589 ***


Note You need to log in before you can comment on or make changes to this bug.