This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v5] Add and use new glibc-internal futex API.
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>, David Miller <davem at davemloft dot net>
- Date: Thu, 9 Jul 2015 14:34:32 -0700 (PDT)
- Subject: Re: [PATCH v5] Add and use new glibc-internal futex API.
- Authentication-results: sourceware.org; auth=none
- References: <1434987160 dot 25759 dot 26 dot camel at localhost dot localdomain> <20150624232258 dot 9A74C2C3B00 at topped-with-meat dot com> <1435749621 dot 4216 dot 64 dot camel at localhost dot localdomain> <20150702012747 dot 1EECE2C3ABF at topped-with-meat dot com> <1435950241 dot 10077 dot 70 dot camel at localhost dot localdomain>
> This works so far:
> grep -r futex_ | grep '((unsigned int'
OK.
> I believe we can commit this early next week, so you can get your
> testing done. I also want to give David some time to test on sparc too.
NaCl testing is all happy.
> > It wouldn't hurt to write up somewhere, probably on the wiki (though in
> > code comments in this patch would also be fine by me) the known/intended
> > further steps of transition and cleanup in this area.
>
> I added a few notes here: https://sourceware.org/glibc/wiki/Concurrency
Good.
> I've removed the changes to nptl/cancellation.c from this patch because
> I was running into build failures on i686-linux, which happen when calls
> to __libc_fatal() or abort() exist in the code. This seems to happen
> when IS_IN (libc) is true. I don't know why that happens but it seems
> orthogonal to the futex API. Therefore, to move forward with the futex
> API, I choose to simply drop the respective changes from the patch.
>
> Roland, do you have any suggestion how this could be fixed? (You argued
> for calling __libc_fatal there ;) Or anyone else?
I'll look into it.
Thanks,
Roland