cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Asking for the reversion of the pselect() patch

From: Yang Tse <yangsita_at_gmail.com>
Date: Mon, 12 Mar 2007 04:44:57 +0100

2007/3/11, Daniel Stenberg wrote:

> Ok, I'll revert that change again to allow us to discuss and work on this
> topic more first.

I would also like someone to clearly show us the benefits of using
pselect() and ppoll() in libcurl, and what is what we are missing not
using them. In this way both pros and cons could be evaluated.

Besides what Jamie Lokier has already said:

Some generics against using pselect() and ppoll()...

Basically portability, and reliability issues on nearly all platforms.
And even on specific platform, different implementations depending on
OS version or kernel version. All this is something that for sure will
introduce debugging nightmare issues which most probably nobody will
have the time to sort out. Or those who have the time won't have the
platform to test and debug it, and the contrary.

For example Linux...

Glibc 2.0 provided a version of pselect() that did not take a sigmask argument.

Since version 2.1, glibc has provided an emulation of pselect() that
is implemented using sig- procmask(2) and select(). This
implementation remains vulnerable to the very race condition that
pselect() was designed to prevent.

pselect() was added to Linux in kernel 2.6.16. Prior to this,
pselect() was _emulated_ in glibc

Prototype madness: Under glibc 2.0 it unconditionally gives the wrong
prototype for pselect(), under glibc 2.1-2.2.1 it gives pselect() when
_GNU_SOURCE is defined, under glibc 2.2.2-2.2.4 it gives it when
_XOPEN_SOURCE is defined and has a value of 600 or larger.

I think trying to use this is quite insane. Unless the benefits it
reports highly outweighs all the problems.

-- 
-=[Yang]=-
Received on 2007-03-12