On Mon, 2004-12-20 at 13:03 +0100, Daniel Stenberg wrote:

> > 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.

There is a precedent in Transfer() in transfer.c.

Also see:
http://seclists.org/lists/linux-kernel/2000/Nov/1225.html
http://www.gnu.org/software/libc/manual/html_node/Interrupted-Primitives.html#Interrupted%20Primitives

Basically, if you use some signal handler that set some global flag,
then when you get EINTR you may want to inspect that global state to
determine what to do next. But in the common case that you don't use
signals yourself, and especially if you're a library implementor where
you don't have full knowledge/control of the entire program, you should
restart.

> 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 glibc threads implementation uses realtime signals internally; I
assume its one of those. The comment in Transer() alludes to that.

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

I concur.

> Note that this change is not gonna make it to the 7.12.3 release

Okay, I look forward to seeing a fix in a future release.

Thanks,

-- Martijn
Received on 2004-12-20