Date: Wed, 30 May 2018 11:36:55 +1000 From: Patrick Oppenlander <patrick.oppenlander@...il.com> To: musl@...ts.openwall.com Subject: Re: Re: pthread cancel cleanup and pthread_mutex_lock On Wed, May 30, 2018 at 10:50 AM, Rich Felker <dalias@...c.org> wrote: > This test is invalid. pthread_mutex_lock is not async-cancel-safe and > cannot legally be called while cancel type is async. I suspected as much. > FYI something like 50% of the "Open POSIX Test Suite" tests are > invalid; in the majority of cases they're testing some property after > undefined behavior has been invoked like here. Thanks. Do you know of any better tests? >> I've run this test with musl, glibc and on some different platforms >> with varying results: >> >> x86_64 linux 4.16.11, glibc: test runs to completion >> x86_64 linux 4.16.11, musl: deadlock (cleanup handler doesn't run) >> arm linux 4.16.5, musl: test runs to completion > > The test is invalid in other ways too, involving races. It attempts to > use sched_yield to ensure that the test thread enters > pthread_mutex_lock a second time, but there's no reason to expect that > to do anything, especially if there are sufficiently many cores (as > many or more than running threads). I suspect the different behaviors > come down to just different scheduling properties due to performance > differences, or something like that. Naively, I would expect the test > to "work" despite being invalid. The reason it doesn't "work" (besides being stupid) is because the cleanup handler isn't invoked while the thread is blocked in the pthread_mutex_lock call. Should it be in the async cancellation case? >> What's the expected behaviour here? > > Nothing meaningful. Thanks. Patrick
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.