Message136618
| Author | neologix |
|---|---|
| Recipients | alexey-smirnov, amaury.forgeotdarc, georg.brandl, neologix, petri.lehtinen, pitrou, python-dev, socketpair, vstinner |
| Date | 2011-05-23.12:06:39 |
| SpamBayes Score | 2.2334764e-06 |
| Marked as misclassified | No |
| Message-id | <1306152400.31.0.957876973426.issue12105@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
The real issue is that the libc defines O_CLOEXEC, but kernels prior to 2.6.23 don't support it: instead of returning EINVAL, the socket syscall silently ignores the flag (don't know why I made the comment about this flag being defined to 0...). IMHO this is really a distribution packaging bug (kernel/libc mismatch), and a quite serious one. I don't think we should be fixing this in Python, but that we should merely skip this test on kernels older than 2.6.23. People should complain to their distributions vendors instead (I tested this on RHEL4, RHEL6 and Debian Squeeze without problem). I personally don't like the idea of a best-effort O_CLOEXEC implementation: providing a O_CLOEXEC flag which is not atomic feels really wrong to me. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2011-05-23 12:06:40 | neologix | set | recipients: + neologix, georg.brandl, amaury.forgeotdarc, pitrou, vstinner, socketpair, python-dev, petri.lehtinen, alexey-smirnov |
| 2011-05-23 12:06:40 | neologix | set | messageid: <1306152400.31.0.957876973426.issue12105@psf.upfronthosting.co.za> |
| 2011-05-23 12:06:39 | neologix | link | issue12105 messages |
| 2011-05-23 12:06:39 | neologix | create | |