cURL / Mailing Lists / curl-library / Single Mail

curl-library

RE: interruptible curl_easy_perform()

From: James Dennett <jdennett_at_technocom-wireless.com>
Date: Fri, 16 Feb 2007 09:12:21 -0800

> -----Original Message-----
> From: curl-library-bounces_at_cool.haxx.se [mailto:curl-library-
> bounces_at_cool.haxx.se] On Behalf Of Bryan Henderson
> Sent: Thursday, February 15, 2007 12:44 PM
> To: Curl Library Mailing List
> Subject: interruptible curl_easy_perform()
>
> It ought to be possible to interrupt curl_easy_perform() with a
signal.
>

[snip

> More about pselect(), for those unfamiliar: It's the same as select(),
> except you additionally give it a set of signals to unblock at the
> moment it starts waiting. It re-blocks them before it returns. It is
> a relatively recent addition to POSIX; there are probably systems that
> don't have it. On such a system you can emulate it with sigaction()
> and select(), but that leaves a tiny window in which the process might
> miss a signal and wait anyhow. With older Linux kernels, pselect()
> actually has that same window exposed. Note that isn't any worse than
> libcurl's present logic, in which it _always_ waits in spite of
> receiving signals.

It *is* worse; at present, it's clear that no attempt is made to allow
waiting to be interrupted by a signal, so programmers should not be
tempted to try it. With a racing sigaction/select combination,
programmers might well try it, and find that it usually works, and hence
produce buggy code that falls over in hard to reproduce ways.

The self-pipe trick can be used to work around this *if* an application
doesn't mind doing that from a signal handler; that's fairly portable on
systems that do have POSIX-ish signals.

Not that it might not be worth using pselect where it's available, but a
flawed emulation that fails occasionally is pretty useless for robust
software.

-- James
Received on 2007-02-16