Message143984
| Author |
skrah |
| Recipients |
benjamin.peterson, meador.inge, neologix, skrah, vstinner |
| Date |
2011年09月13日.19:13:58 |
| SpamBayes Score |
5.6244833e-05 |
| Marked as misclassified |
No |
| Message-id |
<20110913191100.GA25752@sleipnir.bytereef.org> |
| In-reply-to |
<1315934774.39.0.412054047579.issue12936@psf.upfronthosting.co.za> |
| Content |
Charles-François Natali <report@bugs.python.org> wrote:
> Out of curiosity, I just looked at the source code, and it just does
> sched_setaffinity(thread->tid), so you can do the same with
> sched_setaffinity(syscall(SYS_gettid)) for the current thread.
sched_setaffinity(syscall(SYS_gettid), size, cpusetp) crashes, too.
This seems to be a violation of the man page, which states:
"The value returned from a call to gettid(2) can be passed in
the argument pid."
Unless one uses a somewhat warped interpretation that linking
against pthread constitutes "using the POSIX threads API". That
would be the only loophole that would allow the crash.
> However, I don't think we should/could add this to the posix module:
> it expects a pthread_t instead of a PID, to which we don't have access.
If we have access (and as I understood from Victor's post we do):
pthread_getaffinity_np() also exists on FreeBSD, which would be
an advantage.
> So I'd suggest closing this issue.
I don't care strongly about using pthread_getaffinity_np(), but at least I'd
like to skip the scheduling sections on arm-linux if they don't work reliably. |
|