This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients alexey-smirnov, amaury.forgeotdarc, georg.brandl, neologix, petri.lehtinen, pitrou, python-dev, socketpair, vstinner
Date 2011-05-23.12:27:07
SpamBayes Score 3.97098e-08
Marked as misclassified No
Message-id <1306153628.61.0.335243341535.issue12105@psf.upfronthosting.co.za>
In-reply-to
Content
> This is a kernel bug, not a bug in the GNU libc (ask Ulrich if you are not sure ;-)).

Kernels prior to 2.6.23 didn't know about the O_CLOEXEC flag: to catch this kind of problem, every syscall would have to check every bit when it's passed a combination of flags. This would be clumsy, error-prone and slow.
It's not a libc bug either.
The problem is really a distribution issue: using a libc defining a flag unsupported by the kernel is really calling for trouble.

> An host can have multiple kernel versions (and choose at boot time using GRUB/LILO/...)

It's possible, but it's definitely a bad idea, because of such API mismatch. For example nothing prevents a syscall from being removed/modified from one kernel version to another. If your libc doesn't follow, you're up for trouble.
Try using futexes with a kernel not supporting them :-)
History
Date User Action Args
2011-05-23 12:27:08neologixsetrecipients: + neologix, georg.brandl, amaury.forgeotdarc, pitrou, vstinner, socketpair, python-dev, petri.lehtinen, alexey-smirnov
2011-05-23 12:27:08neologixsetmessageid: <1306153628.61.0.335243341535.issue12105@psf.upfronthosting.co.za>
2011-05-23 12:27:08neologixlinkissue12105 messages
2011-05-23 12:27:07neologixcreate