Charles-François Natali <neolo...@free.fr> added the comment: > Do you mean that signal.pthread_kill() should be removed? This function is > very useful and solve some issues that cannot be solved differently. At the > same time, I don't think that it's possible to workaround the crashes. At > least, I don't see how: pthread_kill(tid, 0) is supposed to check if tid > exists, but it does crash...
No, I don't suggest to remove it, it is useful. As for the crashes, with glibc pthread_t is really a pointer, so there's no way to check its validity beforehand. Even if we did check the thread ID against the list of Python-created threads IDs (stored in Thread._ident), this could still crash, because the ID becomes invalid as soon as the thread terminates (all threads are started detached). Furthermore, this wouldn't work for non-Python created threads. > We cannot use the same name for two different C function. One expects a > process identifier, whereas the other expects a thread identifier! If Python > is compiled without thread, the thread will not exist (as some modules and > many other functions). > I know, that's why I said "different API": but I must admit it was poorly worded ;-) However, this wouldn't solve this particular problem: as long as we expose sched_setaffinity(), it will crash as soon as someone passes `0` or getpid() as PID. >> pthread_setaffinity_np() is really non-portable >> (it's guarded by __USE_GNU in my system's header) > > We can check it in configure. We already use some functions which are GNU > extensions, like makedev(). Oh, os.makedev() availability is just not > documented :-) As I said, this wouldn't solve this problem. If someone deems it necessary, we can open another issue for this feature request. >> sched_setaffinity() seems to work fine on most systems >> even when linked with pthread > > Again, it looks like a libc/kernel bug. I don't think that Python can work > around such issue. > Agreed. > I don't know or need (), but the difference between sched_setaffinity and > pthread_getaffinity_np is the same between sigprocmask() and > pthread_sigmask(). I chose to expose only the later because the behaviour of > sigprocmask is undefined in a process using threads. Exactly. However, nothing prevents someone from using sigprocmask() in a multithreaded process, the only difference is that it won't crash (AFAICT). So I suggest to: 1) skip the problematic tests on ARM when built with threads to avoid segfaults 2) if someone wants pthread_getaffinity_np(), then we can still open a separate feature request ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12936> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
