On 2025-07-04, Ingo Schwarze wrote:
> Hello Ted,

> OK schwarze@.

thanks.

> I realize you did not add the following sentence:
> 
>      The results of acquiring a read lock while the calling thread
>      holds a write lock are undefined.
> 
> That sentence is already in pthread_rwlock_rdlock(3), but it
> contradicts our own manual page, which says:

I deleted that.

> Looking at our code, my impression is that this EDEADLK behaviour
> is described correctly and we conform to POSIX in this respect,
> so i think you should simply delete the two lies about undefined

We have other lies, however. pthread_rwlock_unlock never returns any
errors. I have left this for now. I think the entire library needs a
fact check.

> Below HISTORY, the "first appeared in FreeBSD 3.0" might be a lie -
> or are the functions really FreeBSD inventions?  Also, you lost part
> of the OpenBSD history.  I'd suggest dropping the FreeBSD history
> and simply saying:

I dropped the section. Very few of the other pages seem to have it.
I don't think it's very useful? We can add it back, but I'd prefer to
consistent. We have some text in pthreads.3 about the library, maybe that
can be expanded.

> The STANDARDS section should probably be updated, -susv2 sounds
> unusually old-fashioned, but no need to mix that into this diff.

Yeah, that needs checking and consistency.

I don't really like the "expected to conform" language. We don't know?
But I also don't like "conforms to" language. Did we check? We have this
language everywhere, but maybe we can consider it again.

What about saying "These functions are specified by .."?