Message136624
| 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 :-) |
|