On 2020-02-08 13:05, Peter Pentchev wrote: > Apparently glibc really, really doesn't believe in cancelling a thread > that has already completed... I'm not really sure what to think about > that, since, well, the thread hasn't been joined yet, so technically it > still exists, albeit in a zombie-like state - and a little test program > of mine shows that even after a thread has exited and pthread_cancel() > returns ESRCH, a call to pthread_join() will succeed and will provide > the correct value returned by the thread function. I'm not sure whether > this is glibc or the Linux kernel or something else - the behavior is > the same on three systems I've tested it on: [...] Ok, this is definitely a bug: pthread_cancel is absolutely supposed to work on threads which have exited but not joined yet.
Can you produce a minimal test case which exhibits this so that it can be reported upstream (to glibc or Linux kernel folks -- I'm not sure who but hopefully they can forward to each other if we get it wrong)? > So I could keep the check for ESRCH as a Debian-specific patch, or you > could make it conditional on __linux__ or __gnu_linux__ or something > similar. What do you think? My general policy with "operating system doesn't do what POSIX says it should" is to have "#ifdef POSIXFAIL_FOO" in the code and a test as part of libcperciva/POSIX/posix-cflags.sh which defines that macro on the appropriate systems (which might just be "anything Linux" for now, but in the future might depend on the version of glibc). -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
