[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] [PATCH] Use pselect() to reduce wakeups and avoid race co

From: Dave Platt
Subject: Re: [gpsd-dev] [PATCH] Use pselect() to reduce wakeups and avoid race conditions
Date: Fri, 13 Jan 2012 15:54:03 -0800
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20111110 Iceowl/1.0b1 Icedove/3.0.11

> glibc has to provide a POSIX API to the apps compiled against it.  if the 
> kernel glibc is running on cannot provide the corresponding functionality, it 
> often has fallback logic to emulate it as best it can.  in this case, 
> pselect() cannot be implemented completely in userspace ... it requires 
> kernel 
> support to be bulletproof.
> i'm not sure what else you can reasonably expect glibc to do ... certainly 
> calling abort() is worse imo.

Well... the problem is that in this case, it's providing a "POSIX API"
emulation which doesn't actually implement the API's functionality
according to spec (and, as you point out, it cannot).  Worse, it
does so "silently" - the program appears to run, but the one
critical characteristic for which pselect() was designed, is the
very one not provided, and this can lead to delayed and unpredictable

I appreciate the desire to be "API compliant", but in this case
the "convenience" provided by glibc is a bit like the old
prayer... "May God protect me from my friends - my enemies, I
can handle!"

Personally I'd prefer to either not implement the function at all
(and acknowledge that on this particular system, glibc is unable
to be fully POSIX-compliant), or print a short warning the first
time pselect() is called on such a system.  Or, maybe, move
the pselect() stub into a separate library which must be
explicitly linked in rather than auto-fetched, so that it's
more apparent that the programmer is explicitly accepting the
use of a noncompliant emulation.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]