[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.
