[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patches] [PATCH] Fix pthread_mutex_unlock.man recursive semantic
- To: Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>
- Subject: Re: [patches] [PATCH] Fix pthread_mutex_unlock.man recursive semantic
- From: "Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>
- Date: Wed, 11 Nov 2009 00:57:14 +0000 (UTC)
On Sun, 8 Nov 2009, Samuel Thibault wrote:
> Joseph S. Myers, le Sun 08 Nov 2009 00:42:29 +0000, a écrit :
> > On Fri, 6 Nov 2009, Samuel Thibault wrote:
> > > There is a small error in the pthread_mutex_unlock manpage: as required
> > > by the POSIX norm, recursive mutexes do check that its caller is the
> > > owner of the lock.
> >
> > What system are you using that supports Linuxthreads with current EGLIBC
> > (so supports TLS) but not NPTL?
>
> I'm not. But Debian uses the linuxthreads manpages for thread stuff.
I think doing so, and taking them from an almost-obsolete legacy part of
EGLIBC, is a mistake. The primary documentation of EGLIBC is the Texinfo
manual, which unfortunately lacks pthreads documentation. Neither EGLIBC
nor FSF GLIBC generally maintains manpages for the contained functions;
instead, there is a separate project that does so, the Linux Man-pages
Project. It really would be better for these pages to be adopted by that
project and maintained there.
I'll apply the patch as it appears to be correct, but I strongly advise
finding another home to maintain manpages that cover both Linuxthreads and
NPTL, and suggest the Linux Man-pages Project as that home.
(The timezone data is a successful case of something being imported into
GLIBC without being maintained there. It would be good if locale data
were maintained externally on a similar basis, and it's not clear all the
miscellaneous utilities installed by (E)GLIBC need to come with the
library either (for example, because of being closely tied to private
datastructures or being needed to run the testsuite); (E)GLIBC should keep
its focus on the actual libraries and things closely tied up with them.)
--
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx