Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> On 08/09/10 20:36, Markus Wanner wrote:
>> It should be possible to reliably determine the platforms that provide
>> an atomic pselect(). For those, I'm hesitant to use a "trick", where
>> pselect() clearly provides a simpler and more "official" alternative.
>> Especially considering that those platforms form the vast majority for
>> running Postgres on.
> Perhaps, but I'm equally concerned that having different implementations
> for different platforms means that all implementations get less testing
> than if we use only one.
There's that, and there's also that Markus' premise is full of holes.
Exactly how will you determine that pselect is safe at compile time?
Even if you correctly determine that, how can you be sure that the
finished executable will only be run against a version of libc that has
a safe implementation? Considering that we know that major platforms
such as FreeBSD have changed their implementations *very* recently,
it seems foolish to assume that an executable built on a machine with
corrected pselect could not be run on one with an older implementation.
> Because of that I'm actually reluctant to even
> use poll() where available instead of select(). At least in the first
> phase, until someone demonstrates that there's a measurable difference
> in performance.
select() is demonstrably a loser whenever the process has a lot of open
files. Also, we have plenty of experience with substituting poll() for
select(), so I'm not too worried about copy-and-pasting such code.
regards, tom lane