cURL / Mailing Lists / curl-library / Single Mail



From: Yang Tse <>
Date: Wed, 17 Aug 2011 17:10:32 +0200

2011/8/17 Daniel Stenberg wrote:

> Back in March 2007 (commit e4b754f64ed02ce85f6deb) we added code that would
> allow libcurl to build with more rigid EINTR code for select/poll if you
> defined CURL_ACKNOWLEDGE_EINTR at compile time.
> Have anyone ever used it or see a point in keeping it?

When CURL_ACKNOWLEDGE_EINTR is defined at compile time, EINTR will be
honored and libcurl will break out of loop when select/poll returns -1
and errno is not zero.

When CURL_ACKNOWLEDGE_EINTR is not defined (default setting) at
compile time, EINTR will be be ignored and libcurl will break out of
loop when select/poll returns -1 and errno is "not zero and not

The default setting ensures that EINTR signal which do not belong to
libcurl process/thread, but that are equally delivered to libcurl
process/thread does not interfere with libcurl internals.

The default setting allows smooth operation in all circumstances given
that libcurl only makes calls too these function with quite short
timeouts, but long enough to not busy loop.

Allowance for the non default setting of CURL_ACKNOWLEDGE_EINTR was
due to someone not wanting libcurl to wait the minimal timeout libcurl
uses when calling into these functions when killing their app.

I believe that the default behavior should probably be kept around due
tu the fact that EINTR signal delivery into libcurl process/thread is
system dependant.

And if the default is to be kept around, why not also keep the
possibility of doing the opposite?

> The reason I ask is that we just now got a bug report (on Symbian - bug
> 3392945) due to the support code for EINTR that does a loop if 'errno' is 0
> or EINTR, which for some reason happens here.

Daniel, please ;-) ...

The report is that select returns -1 with errno zero. It really
doesn't matter if afterwards errno is checked against EINTR or

The report is also relative to a user built example, running on an
emulator. Given the very restrictive conditions that Dan mentions in
packages/Symbian/readme.txt needed to minimally be able to build curl
as a Symbian app. I would ask the bug reporter if it is possible to
repeat the problem with the curl app and libcurl library built exactly
as it is mentioned in packages/Symbian/readme.txt and using project
files provided in packages/Symbian. I'm pretty sure that the bug
report is a PBKAC doing something funny, who knows what, but as a
result that build is not addressing appropriately errno, and for that
reason sees a zero errno. Just guessing!!

List admin:
Received on 2011-08-17