[Python-Dev] Handling support for newer OS features at run time

[Matthias Klose]

Am 28.11.2012 06:37, schrieb Gregory P. Smith:
> On Tue, Nov 27, 2012 at 3:19 PM, Trent Nelson <trent at snakebite.org> wrote:
> 
>> On Tue, Nov 27, 2012 at 03:09:12PM -0800, Matthias Klose wrote:
>>> Am 27.11.2012 23:49, schrieb Trent Nelson:
>>>>     I don't think we've currently got the ability to do this, right?
>>>>     Is there a precedent set anywhere else?  I suspect it's not as
>>>>     much of an issue on *NIX platforms as you'll typically compile
>>>>     from source.  Windows, not so much.
>>>>
>>>>     Thoughts?  A single binary that dynamically loads applicable
>>>>     modules seems cleaner but will obviously take more work.  Other
>>>>     approach would be to start distributing multiple versions of
>>>>     Python based on the underlying Windows version.  Not the nicest
>>>>     approach.
>>>
>>> Usually I have to build a python package on a build daemon running the
>>> kernel of the latest stable (or latest stable long term support)
>>> release.  Thus if a configure test checks the current kernel, then you
>>> may get an unexpected answer and a missing feature. It is somehow
>>> different that I already build different binaries (per release), but
>>> the hard-coding of kernel features during configure time looks like
>>> the same issue. Currently working around it by patching configure to
>>> remove the test and hard-code it for a particular build. Another
>>> solution maybe would to have something like --enable-kernel=<version>
>>> (as found in glibc), and hope that you can deduce the features from
>>> the kernel version.
>>
>>     Hmmm.  How often do Linux kernel versions expose new features that
>>     we can make use of in Python?  i.e. do you run into this problem
>>     often?  Can you cite some recent examples?
>>
> 
> Here's an example of using the pipe2() system call. The code is only
> compiled in if the C library supports it. If the C library supports it, the
> system call can still return an error because the running kernel doesn't
> support it (ENOSYS). In that case it falls back to the legacy code:
> 
> 
> http://hg.python.org/cpython/file/618ea5612e83/Modules/_posixsubprocess.c#l738

another one is the check for working semaphores for the multiprocessing module,
seen at https://launchpad.net/bugs/630511